Client application with dynamic user interface

ABSTRACT

A method includes presenting an initial user interface to a user that includes a first field including a first graphical depiction of a first object associated with the user and a second field including a second graphical depiction. The method also includes receiving an indication of a user interaction with the first field, and dynamically updating the initial user interface responsive to determining that the user interaction is a user selection of a second object to create an updated user interface. The updated user interface includes an updated first field including a depiction of the second object, and an updated second field including a third graphical depiction.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a Continuation of U.S. patent application Ser. No.15/604,242, entitled “MOBILE WALLET CARD CAROUSEL,” filed May 24, 2017,which claims the benefit of and priority to U.S. Provisional PatentApplication No. 62/458,937 entitled “SYSTEMS AND METHODS FOR A MOBILEWALLET,” filed on Feb. 14, 2017, both of which are incorporated hereinby reference in their entireties.

BACKGROUND

Today, purchases are accomplished in a variety of ways from conventionalcash or currency to now electronic-based transactions. While there are avariety of electronic-based transactions, one type is via a mobiledevice. For example, mobile device users may purchase goods and servicesthrough payment applications at point-of-sale terminals. Beneficially,the use of their mobile device to make payments at the point-of-saleterminal may alleviate or reduce the need to carry cash or payment cards(e.g., credit cards), which some users may find appealing.

SUMMARY

One embodiment relates to a computer-implemented method. The methodincludes receiving, by a mobile wallet computing system, payment vehicleinformation for provisioning a first payment vehicle to a mobile walletof a user, the first payment vehicle being associated with a financialinstitution. The method also includes identifying, by the mobile walletcomputing system, a first functionality pertaining to the paymentvehicle, wherein the first functionality enables the user to indicate atransaction preference for a transaction with an entity other than thefinancial institution. The method also includes presenting, by themobile wallet computing system, a mobile wallet interface to a userassociated with a mobile wallet. The mobile wallet interface includes afirst field that includes a graphical depiction of the payment vehicle,the first field including a first interaction point configured to enablea mobile wallet transaction. The mobile wallet interface also includes asecond field that includes a second interaction point and a thirdinteraction point, the second interaction point enabling the user toaccess the first functionality, the third interaction point enabling theuser to indicate a preference to initiate communications with thefinancial institution to perform at least one account managementfunction related to the first payment vehicle depicted in the firstfield, wherein the first interaction point, second interaction point,and third interaction point are all simultaneously viewable on themobile wallet interface without any user interactions with the mobilewallet interface.

Another embodiment relates to a system. The system includes a mobilewallet database structured to store information pertaining to a mobilewallet associated with a user. The system also includes a networkinterface configured to communicate data to and from a user mobiledevice associated with a user, and a plurality of third party computingsystems. The system also includes a mobile wallet circuit, the mobilewallet circuit being communicatively coupled to the mobile walletdatabase and the network interface. The mobile wallet circuit isstructured to receive, by the network interface, payment vehicleinformation for provisioning a first payment vehicle to a mobile wallet,the payment vehicle being associated with a financial institution. Themobile wallet circuit is also structured to identify a functionalitypertaining to the payment vehicle, wherein the functionality includesreceiving a user preference for a transaction with an entity other thanthe financial institution. The mobile wallet circuit is also structuredto present, by the network interface, a mobile wallet interface to theuser via the user mobile device. The mobile wallet interface includes afirst field that includes a graphical depiction of the first paymentvehicle, the first field including a first interaction point configuredto enable a point of sale mobile wallet transaction using the firstpayment vehicle. The mobile wallet interface also includes a secondfield that includes a second interaction point and a third interactionpoint, the second interaction point configured to receive a userpreference to access the identified functionality, the third interactionpoint configured to receive a user preference to initiate communicationswith the financial institution related to the first payment vehicledepicted in the first field, wherein the first interaction point, secondinteraction point, and third interaction point are all simultaneouslyviewable on the mobile wallet interface without any user interactionswith the mobile wallet interface.

Another embodiment relates to a mobile device. The mobile deviceincludes a network circuit structured to communicate data to and from amobile wallet computing system. The mobile device also includes aninput/output structured to exchange data with a user. The mobile devicealso includes a mobile wallet circuit communicatively coupled to thenetwork circuit and the input/output device. The mobile wallet circuitis structured to present a mobile wallet interface to the user viainput/output. The mobile wallet interface includes a first field thatincludes a graphical depiction of a user payment vehicle at a financialinstitution, the first field including a first interaction pointcommunicably coupled to a near field communications chip on the mobiledevice. The mobile wallet interface also includes a second field thatincludes a second interaction point and a third interaction point, thesecond interaction point configured to receive a user preference toengage in a transaction with an entity other than the financialinstitution, the third interaction point configured to initiatecommunications with the financial institution, wherein the firstinteraction point, second interaction point, and third interaction pointare all simultaneously viewable on the mobile wallet interface withoutany user interactions with the mobile wallet interface.

Another embodiment relates to a computer-implemented method. The methodincludes presenting, by a mobile device, an initial mobile walletinterface to a user associated with a mobile wallet. The initial mobilewallet interface includes a first field including a first paymentvehicle depiction of a first payment vehicle associated with the userand a second field including a first payment-related service graphicaldepiction of a first payment-related service. The method also includesreceiving, by the mobile device, an indication of a user interactionwith the first field. The method also includes determining, by thedevice, that the user interaction with the first field constitutes auser selection of a second payment vehicle. The method also includesdynamically updating, by the mobile device, the mobile wallet interfaceresponsive to determining that the user interaction is a user selectionof the second payment vehicle. The updated mobile wallet interfaceincludes an updated first field including a second payment vehicledepiction of a second payment vehicle and an updated second fieldincluding a second payment-related service graphical depiction of asecond payment-related service, the second payment-related service beingdifferent from the first payment-related service.

Another embodiment relates to a mobile device. The mobile deviceincludes a network circuit structured to communicate data to and from amobile wallet computing system. The mobile device also includes aninput/output structured to exchange data with a user. The mobile devicefurther includes a mobile wallet circuit communicatively coupled to thenetwork circuit and the input/output device. The mobile wallet circuitis structured to present, via the input/output, a an initial mobilewallet interface to a user associated with a mobile wallet. The initialmobile wallet interface includes a first field including a first paymentvehicle depiction of a first payment vehicle associated with the userand a second field including a first payment-related service graphicaldepiction of a first payment-related service. The mobile wallet circuitis further structured to receive, by the input/output, an indication ofa user interaction with the first field. The mobile wallet circuit isfurther structured to determine that the user interaction with the firstfield constitutes a user selection of a second payment vehicle. Themobile wallet circuit is further structured to dynamically update themobile wallet interface responsive to determining that the userinteraction is a user selection of the second payment. The updatedmobile wallet interface includes an updated first field including asecond payment vehicle depiction of a second payment vehicle and anupdated second field including a second payment-related servicegraphical depiction of a second payment-related service, the secondpayment-related service being different from the first payment-relatedservice.

Another embodiment relates to non-transitory computer readable mediahaving computer-executable instructions embodied therein that, whenexecuted by a processor of a mobile device, cause the processor toperform operations. The operations include presenting an initial mobilewallet interface to a user associated with a mobile wallet, the initialmobile wallet interface including a first field including a firstpayment vehicle depiction of a first payment vehicle associated with theuser and a second field including a first payment-related servicegraphical depiction of a first payment-related service. The operationsfurther include receiving an indication of a user interaction with thefirst field. The operations further include determining that the userinteraction with the first field constitutes a user selection of asecond payment vehicle. The operations further include dynamicallyupdating the mobile wallet interface responsive to determining that theuser interaction is a user selection of the second payment vehicle, theupdated mobile wallet interface including an updated first fieldincluding a second payment vehicle depiction of a second payment vehicleand an updated second field including a second payment-related servicegraphical depiction of a second payment-related service, the secondpayment-related service being different from the first payment-relatedservice.

Another embodiment relates to a computer-implemented method. The methodincludes retrieving, by a financial institution computing systemassociated with a financial institution, information pertaining to anexisting account of a mobile wallet user from a database. The methodfurther includes determining, by the financial institution computingsystem, the user's qualification for a credit card offer by comparingthe retrieved information to predetermined criteria, wherein thedetermining involves underwriting the user for a credit card offer basedon the information pertaining to the existing account. The methodfurther includes selecting, by the financial institution computingsystem, a set of credit card offer terms for the credit card offer basedon the existing account based on the user's qualification. The methodfurther includes presenting, by the financial institution computingsystem, the user with a depiction of at least a portion of the selectedset of credit offer terms in the user's mobile wallet, the depictionbeing proximate to an interaction point configured to receive a userpreference to accept or decline the credit card offer.

Another embodiment relates to a system. The system includes a customeraccount database structured to store customer information regarding aplurality of customers of a financial institution that are also mobilewallet users. The system also includes a network interface configured tocommunicate data to and from a plurality of mobile devices associatedwith a plurality of customers. The system also includes a creditapproval circuit, the credit approval circuit being communicativelycoupled to the customer database, and the network interface. The creditapproval circuit is structured to retrieve information pertaining to anexisting account of a mobile wallet user from a database. The customcredit approval circuit is further structured to determine the user'squalification for a credit card offer by comparing the retrievedinformation to predetermined criteria, wherein the determining involvesunderwriting the user for a credit card offer based on the informationpertaining to the existing account. The custom credit approval circuitis further structured to select a set of credit card offer terms for thecredit card offer based on the existing based on the user'squalification. The custom credit approval circuit is further structuredto present, by the network interface, the user with a depiction of atleast a portion of the selected set of credit offer terms t in theuser's mobile wallet, the depiction being proximate to an interactionpoint configured to receive user a preference to accept or decline thecredit card offer.

Another embodiment relates to a mobile device. The mobile deviceincludes a network circuit structured to communicate data to and from afinancial institution computing system associated with a financialinstitution and mobile wallet computing system associated with a mobilewallet provider. The mobile device also includes an input/outputstructured to exchange data with a customer. The mobile device alsoincludes a mobile wallet circuit communicatively coupled to the networkcircuit and the input/output device. The mobile wallet circuit isstructured to. receive, by the network circuit, identifying informationfor a pre-authorized credit card account that has been offered to thecustomer. The mobile wallet circuit is further structured to present, bythe input/output, a first mobile wallet interface to a customer, themobile wallet interface including an account selection portion includinga depiction of an account that the customer has provisioned to a mobilewallet and a depiction of the pre-authorized credit card account,wherein the account selection portion can be manipulated by the customerto select either the provisioned account or the pre-authorized creditcard account. The mobile wallet circuit is further structured toreceive, by the input/output, a first input from the customer indicatinga customer selection of the pre-authorized credit card account. Themobile wallet circuit is further structured to present, by theinput/output, the depiction of the pre-authorized credit card account tothe user, wherein the depiction of the pre-authorized credit cardaccount includes at least one credit card offer term and includes aninteraction point configured to receive preference a second user inputto accept the pre-authorized credit card account.

Another embodiment relates to a computer-implemented method. The methodincludes receiving, by a mobile wallet computing system, a request toregister for a mobile wallet from a user mobile device. The method alsoincludes transmitting, by the mobile wallet computing system, aninformation request to the user mobile device, the information requestprompting the user to provide information. The method also includesreceiving, by the mobile wallet computing system, user-input informationfrom the user mobile device. The method also includes determining, bythe mobile wallet computing system, that the user has an account at afinancial institution associated with the mobile wallet computing systembased on the user-input information. The method also includesretrieving, by the mobile wallet computing system, informationpertaining to the account. The method also includes transmitting, by themobile wallet computing system, a mobile wallet client application tothe mobile device, the mobile wallet client application being configuredto present the user with a mobile wallet interface. The method alsoincludes selecting, by the mobile wallet computing system, a set ofservices from a plurality of services associated with variousfunctionalities included in the transmitted mobile wallet clientapplication to make accessible to the user based on at least one of theuser-input information and the information pertaining to the account.The method also includes transmitting, by the mobile wallet computingsystem, a set of instructions to the mobile device, the set ofinstructions identifying a set of graphical depictions to include in themobile wallet interface, the set of graphical depictions including adepiction of at least one of the selected services.

Another embodiment relates to a system. The system includes a mobilewallet database structured to store information pertaining to the mobilewallets of a plurality of mobile wallet users. The system also includesa network interface configured to communicate data to and from a usermobile device associated with a user and a plurality of third partycomputing systems. The system also includes a mobile wallet circuit, themobile wallet circuit being communicatively coupled to the mobile walletdatabase and the network interface. The mobile wallet circuit isstructured to receive, by the network interface, a request to registerfor a mobile wallet from a user mobile device. The mobile wallet circuitis also structured to transmit, by the network interface, an informationrequest to the user mobile device, the information request prompting theuser to provide information. The mobile wallet circuit is alsostructured to receive, by the network interface, user-input informationfrom the user mobile device. The mobile wallet circuit is alsostructured to determine that the user has an account at a financialinstitution associated with the mobile wallet computing system based onthe user-input information. The mobile wallet circuit is also structuredto retrieve information pertaining to the account from an accountdatabase. The mobile wallet circuit is also structured to transmit, bythe network interface, a mobile wallet client application to the mobiledevice, the mobile wallet client application being configured to presentthe user with a mobile wallet interface. The mobile wallet circuit isalso structured to select a set of services from a plurality of servicesassociated with various functionalities included in the transmittedmobile wallet client application to make accessible to the user based onat least one of the user-input information and the informationpertaining to the account. The mobile wallet circuit is furtherstructured to transmit a set of instructions to the mobile device, theset of instructions identifying a set of graphical depictions to includein the mobile wallet interface, the set of graphical depictionsincluding a depiction of at least one of the selected services.

Another embodiment relates to a non-transitory computer readable mediahaving computer-executable instructions embodied therein that, whenexecuted by a mobile wallet circuit of a mobile wallet system, causesthe mobile wallet computing system to perform operations to register auser for a mobile wallet. The operations include receiving a request toregister for a mobile wallet from a user mobile device. The operationsinclude transmitting an information request to the user mobile device,the information request prompting the user to provide information. Theoperations further include receiving user-input information from theuser mobile device. The operations further include determining that theuser has an account at a financial institution associated with themobile wallet computing system based on the user-input information. Theoperations further include retrieving information pertaining to theaccount. The operations further include transmitting a mobile walletclient application to the mobile device, the mobile wallet clientapplication being configured to present the user with a mobile walletinterface. The operations further include selecting a set of servicesfrom a plurality of services associated with various functionalitiesincluded in the transmitted mobile wallet client application to makeaccessible to the user based on at least one of the user-inputinformation and the information pertaining to the account. Theoperations further include transmitting a set of instructions to themobile device, the set of instructions identifying a set of graphicaldepictions to include in the mobile wallet interface, the set ofgraphical depictions including a depiction of at least one of theselected services.

Another embodiment relates to a computer-implemented method. The methodincludes receiving, by a mobile wallet computing system, an indicationfrom a user to install a mobile wallet client application on a userdevice. The method also includes receiving, by the mobile walletcomputing system, registration information to install the mobile walletclient application including information regarding a first paymentaccount associated with the user. The method also includes determining,by the mobile wallet computing system, that the first payment account isnot associated with a token. The method also includes registering, bythe mobile wallet computing system, the user for the mobile walletclient application, wherein the registration includes providing themobile wallet client application on the user device, the mobile walletclient application configured to present the user with a mobile walletinterface, wherein the mobile wallet interface includes a graphicaldepiction of the first payment account and an account management portionconfigured to receive a user input to perform at least one accountmanagement function regarding the first payment account even if no tokenis generated for the first payment account.

Another embodiment relates to a mobile device. The mobile devicesincludes a network circuit structured to communicate data over anetwork. The mobile device also includes an input/output configured toexchange data with a user. The mobile device also includes a processor.The mobile device also includes a memory coupled to the processor, thememory having mobile wallet client application stored thereon, themobile wallet client application including instructions executable bythe processor that are structured to cause the processor to receive, viathe input/output, an indication to turn on the mobile wallet clientapplication. The instructions also cause the processor to identify afirst payment account in the mobile wallet client application held bythe user responsive to receiving the indication. The instructions alsocause the processor to determine that the first payment account is nottokenized within the mobile wallet client application. The instructionsalso cause the processor to present, via the input/output, a mobilewallet interface to the user prior to taking any steps to generate atoken for the first payment account, the mobile wallet interfaceincluding a first depiction of the first payment account and a seconddepiction of at least one action that the user can take using the firstpayment account, the at least one action including at least one ofviewing an account balance associated with the first payment account andperforming an account management function with respect to the firstpayment account.

A computer-implemented method. The method includes receiving, by afinancial institution computing system associated with a financialinstitution, a request to register for a mobile wallet from a usermobile device. The method also includes identifying, by the financialinstitution computing system, a first payment account held by the user.The method also includes transmitting, by the mobile wallet computingsystem, a tokenization prompt to the user mobile device, thetokenization prompt instructing the user to indicate a tokenizationpreference for the first payment account. The method also includesreceiving, by the mobile wallet computing system, a user tokenizationpreference to not tokenize the first payment account. The method alsoincludes presenting, by the mobile wallet computing system, a mobilewallet interface on the user mobile device, the mobile wallet interfaceincluding a first graphical depiction of the first payment account aswell as a second graphical depiction of at least one action that theuser can take using the first payment account, the at least one actionincluding at least one of viewing an account balance associated with thefirst payment account and performing an account management function withrespect to the first payment account.

Another embodiment relates to a mobile device. The mobile deviceincludes a network circuit structured to communicate data over anetwork. The mobile device also includes an input/output configured toexchange data with a user. The mobile device also includes a processor.The mobile device also includes a memory coupled to the processor, thememory having mobile wallet client application stored thereon, themobile wallet client application including instructions executable bythe processor that are structured to cause the processor to receive, viathe input/output, a user input to access mobile wallet clientapplication. The instructions also cause the processor to identify afirst payment account and a second payment account held by the userresponsive to receiving the user input, wherein the first paymentaccount is activated such that the first payment account is associatedwith a first token and useable in mobile wallet transactions, andwherein the second payment account is deactivated such that the secondpayment account is unusable in mobile wallet transactions. Theinstructions also cause the processor to present, via the input/output,a mobile wallet interface to the user, the mobile wallet interfaceincluding a first depiction of the first payment account and a seconddepiction of the second payment account, wherein the second depictionincludes a contrasting aspect relative to the first depiction toindicate that the second payment account is deactivated.

Another embodiment relates to a computer-implemented method. The methodincludes receiving, by a mobile device, a user input to activate themobile wallet client application. The method also includes identifying,by the mobile device, a first payment account and a second paymentaccount held by the user responsive to receiving the user preference,wherein the first payment account is activated such that the firstpayment account is associated with a first token and useable in mobilewallet transactions, and wherein the second payment account isdeactivated such that the second payment account is unusable in mobilewallet transactions. The methods also include presenting, by the mobiledevice, a mobile wallet interface to the user, the mobile walletinterface including a first depiction of the first payment account and asecond depiction of the second payment account, wherein the seconddepiction includes a contrasting aspect relative to the first depictionto indicate that the second payment account is deactivated.

Another embodiment relates to a non-transitory computer readable mediahaving computer-executable instructions embodied therein that, whenexecuted by a processor of a mobile device, cause the processor toperform various operations. The operations include receiving a userinput to activate the mobile wallet client application. The operationsalso include identifying a first payment account and a second paymentaccount held by the user responsive to receiving the user preference,wherein the first payment account is activated such that the firstpayment account is associated with a first token and useable in mobilewallet transactions, and wherein the second payment account isdeactivated such that the second payment account is unusable in mobilewallet transactions. The operations also include presenting a mobilewallet interface to the user, the mobile wallet interface including afirst depiction of the first payment account and a second depiction ofthe second payment account, wherein the second depiction includes acontrasting aspect relative to the first depiction to indicate that thesecond payment account is deactivated.

Another embodiment relates to a computer-implemented method. The methodincludes retrieving, by a financial institution computing systemassociated with a financial institution, information pertaining to anexisting account of a mobile wallet user from a database. The methodalso includes underwriting, by the financial institution computingsystem, the user for the credit card offer by comparing the informationpertaining to the existing account to predetermined criteria. The methodalso includes selecting, by the financial institution computing system,a set of credit card offer terms for the credit card offer based on thepre-underwriting. The method also includes modifying, by the financialinstitution computing system, the selected set of credit card offerterms to incorporate at least one credit offer term that is tailored tothe customer based on information regarding the user. The method alsoincludes creating, by the financial institution computing system, acredit card account for the mobile wallet of the user associated withthe credit card offer. The method also includes generating, by thefinancial institution computing system, an account number for the creditcard account associated with the credit card offer. The method alsoincludes presenting, by the financial institution computing system, theuser with a depiction of the credit card account in the user's mobilewallet, the depiction including an option to accept the credit cardoffer in order to activate the credit card account for use in the mobilewallet by the user.

Another embodiment relates to a system. The system includes a customeraccount database structured to store customer information regarding aplurality of customers of a financial institution that are also mobilewallet users. The system also includes a network interface configured tocommunicate data to and from a plurality of mobile devices associatedwith a plurality of customers. The system also includes a creditapproval circuit, the credit approval circuit being communicativelycoupled to the customer database, and the network interface The creditapproval circuit is structured to retrieve information pertaining to anexisting account of a mobile wallet user from the customer accountdatabase. The credit approval circuit is also structured to underwritethe user for the credit card offer by comparing the informationpertaining to the existing account to predetermined criteria. The creditapproval circuit is also structured to select a set of credit card offerterms for the credit card offer based on the pre-underwriting. Thecredit approval circuit is also structured to modify the selected set ofcredit card offer terms to incorporate at least one credit offer termthat is tailored to the customer based on information regarding theuser. The credit approval circuit is also structured to create a creditcard account for the mobile wallet of the user associated with thecredit card offer in the accounts database. The credit approval circuitis also structured to generate an account number for the credit cardaccount associated with the credit card offer. The credit approvalcircuit is also structured to present the user with a depiction of thecredit card account in the user's mobile wallet, the depiction includingan option to accept the credit card offer in order to activate thecredit card account for use in the mobile wallet by the user.

Another embodiment relates to a non-transitory computer readable mediahaving computer-executable instructions embodied therein that, whenexecuted by a processor of a mobile device, cause the processor toperform various operations. The operations include retrievinginformation pertaining to an existing account of a mobile wallet userfrom a database. The operations also include underwriting the user forthe credit card offer by comparing the information pertaining to theexisting account to predetermined criteria. The operations also includeselecting a set of credit card offer terms for the credit card offerbased on the pre-underwriting. The operations also include modifying theselected set of credit card offer terms to incorporate at least onecredit offer term that is tailored to the customer based on informationregarding the user. The operations also include creating a credit cardaccount for the mobile wallet of the user associated with the creditcard offer. The operations also include generating an account number forthe credit card account associated with the credit card offer. Theoperations also include presenting the user with a depiction of thecredit card account in the user's mobile wallet, the depiction includingan option to accept the credit card offer in order to activate thecredit card account for use in the mobile wallet by the user.

Another embodiment relates to a computer-implemented method. The methodincludes presenting, by the mobile device, a mobile wallet interface toa user, the mobile wallet interface including a first depiction of auser payment vehicle and a first icon configured to receive a user inputto take a first action with respect to the first payment vehicle,wherein the first action is at least one of engaging in a point of saletransaction using the first payment vehicle, viewing an account balanceassociated with the first payment vehicle, viewing a transaction historyassociated with the first payment vehicle, performing an accountmanagement function with respect to the first payment vehicle,performing a person-to-person transfer using the user payment vehicle,and engaging in a network transaction using the user payment vehicle.The method also includes determining, by the mobile device, that thefirst input has not been received within a predetermined period. Themethod also includes updating, by mobile device, the mobile walletinterface to not include the first icon responsive to the determination.

Another embodiment relates to a mobile device. The mobile deviceincludes a network interface structured to communicate data to and froma mobile wallet computing system. The mobile device also includes aninput/output structured to exchange data with a user. The mobile devicealso includes mobile wallet circuit structured to present, via theinput/output, a mobile wallet interface to the user, the mobile walletinterface including a first depiction of a user payment vehicle and afirst icon configured to receive a user input to take a first actionwith respect to the first payment vehicle, wherein the first action isat least one of engaging in a point of sale transaction using the firstpayment vehicle, viewing an account balance associated with the firstpayment vehicle, viewing a transaction history associated with the firstpayment vehicle, performing an account management function with respectto the first payment vehicle, performing a person-to-person transferusing the user payment vehicle, and engaging in a network transactionusing the user payment vehicle. The mobile wallet circuit is furtherstructured to determine that the first input has not been receivedwithin a predetermined period. The mobile wallet circuit is furtherstructured to update the mobile wallet interface to not include thefirst icon responsive to the determination.

Another embodiment relates to a non-transitory computer readable mediahaving computer-executable instructions embodied therein that, whenexecuted by a processor of a mobile device, cause the processor toperform various operations. The operations include presenting a mobilewallet interface to a user, the mobile wallet interface including afirst depiction of a user payment vehicle and a first icon configured toreceive a user input to take a first action with respect to the firstpayment vehicle, wherein the first action is at least one of engaging ina point of sale transaction using the first payment vehicle, viewing anaccount balance associated with the first payment vehicle, viewing atransaction history associated with the first payment vehicle,performing an account management function with respect to the firstpayment vehicle, performing a person-to-person transfer using the userpayment vehicle, and engaging in a network transaction using the userpayment vehicle. The operations further include determining that thefirst input has not been received within a predetermined period. Theoperations further include updating the mobile wallet interface to notinclude the first icon responsive to the determination.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a system for providing a multi-functionalmobile wallet, according to an example embodiment.

FIG. 2 is a more detailed diagram of a mobile wallet circuit of thesystem shown in FIG. 1 , according to an example embodiment.

FIG. 3 is a flow diagram of a method of registering a user for a mobilewallet, according to an example embodiment.

FIGS. 4A-4D are example interfaces presented to a user during aregistration process for a mobile wallet.

FIGS. 5A-5D are example mobile wallet interfaces presented to a userduring operation of a mobile wallet on a user mobile device.

FIG. 6 is an example mobile wallet functionality interface presented toa user during operation of a mobile wallet on a user mobile device.

FIG. 7 is an example account history interface presented to a userduring operation of a mobile wallet on a user mobile device.

FIG. 8 is an example mobile wallet loyalty interface presented to a userduring operation of a mobile wallet on a user mobile device.

FIG. 9 is a flow diagram of a method of dynamically updating a set offunctionalities accessible on a mobile wallet interface based on userinteractions with a mobile wallet, according to an example embodiment.

FIG. 10 is a flow diagram of a method of generating a custom credit cardoffer to be presented to a user via a mobile wallet, according to anexample embodiment.

FIG. 11 is a flow diagram of a method of activating the credit cardaccount generated through the method of FIG. 10 , according to anexample embodiment.

FIG. 12 is an example mobile wallet interface depicting a credit cardoffer, according to an example embodiment.

DETAILED DESCRIPTION

Various embodiments discussed herein relate to systems and methods forbundling various functionalities and features into a mobile wallet. Invarious embodiments, a mobile wallet provider presents or otherwiseprovides a mobile wallet interface to a user to enable and allow accessand use of not just mobile wallet functionalities, but a broad array offinancial services. In other words, the mobile wallet interface mayprovide the user with a single access point to mobile wallet features aswell as other features traditionally only accessible elsewhere. Forexample, the mobile wallet interface includes various interaction points(e.g., buttons, links, icons, etc.). A first interaction point mayenable the user to conduct a point of sale transaction using the mobilewallet, while additional interaction points may enable the user toperform more general banking functions such as viewing a balanceassociated with an account, viewing a transaction history associatedwith an account, and setting preferences and rules relating to a paymentvehicle (e.g., authentication preferences, security settings, and thelike). Other interaction points provide access to other functionalitiesassociated with other payment-related services offered by variousentities (e.g., person-to-person transfers, shopping, financial rewards,alerts, issuer-specific deals, and the like). Technically andbeneficially, the integration of payment features, banking features, andthe like within a single system—the mobile wallet—provides an enhancedamount of convenience to users of the mobile wallet of the presentdisclosure. As a result, users may perform tasks (e.g., payments, viewbalances, etc.) in a faster, more efficient manner.

In some arrangements, a multi-field mobile wallet interface is presentedto the user. The multi-field mobile wallet interface may include, forexample, a first field that enables the user to view and select variouspayment vehicles (e.g., credit cards, debit cards, checking accounts,gift cards, and the like) associated with the user. A second field mayprovide the user with access to various payment-related services (e.g.,mobile shopping applications, person-to-person payment (“P2P”) services,and the like) that are related to the payment vehicles viewable in thefirst field. Additionally, the second field may also enable the user totake actions with respect to a payment vehicle viewable in the firstfield (e.g., view a transaction history associated with the paymentvehicle).

In various embodiments, the mobile wallet interface presented to theuser by the systems and methods disclosed herein is individuallytailored to the user. As an example, a user may provide information andrequest to register for a mobile wallet provided by a mobile walletprovider computing system. In response, the mobile wallet providercomputing system provides a mobile wallet application on a user mobiledevice associated with the user that exposes a set of functionalitiesthat is individually tailored to the user based on availableinformation. As a result, the user is efficiently provided with a mobilewallet interface specifically tailored to the user's circumstances.

In various embodiments, the mobile wallet interface is continuously ordynamically updated based on both actions of the mobile wallet user andof other parties. For example, the first field discussed above may bemanipulated by the user to select a particular payment vehicle. Inresponse to the selection, the second field may dynamically update toinclude a set of functionalities that is based on the selected paymentvehicle. This way, the user is presented with a dynamic mobile walletinterface allowing access to the most useful functionalities given theuser's current preferences.

Additionally, the mobile wallet interface may be updated responsive tocertain actions taken by a financial institution. For example, if a userhas an account at the financial institution, the financial institution,via an associated computing system, may pre-approve the user for acredit card that is individually tailored to the user based on theuser's account. The financial institution computing system may alsocommunicate with a card network to create a credit card account numberfor the user, tokenize the account number, and present the user thecredit card offer in the user's mobile wallet. In response to the useraccepting the credit card offer, the pre-authorized credit card accountis immediately provisioned to the user's mobile wallet, and thus quicklyavailable for use in mobile wallet transactions.

Additionally, the systems, methods, and implementations disclosed hereinfurther facilitate a completely digital end-to-end customer engagementprocess for a financial institution. For example, a new customer nothaving an existing account with the financial institution may access awebsite associated with a financial institution via a mobile device andrequest to register/apply for both a credit card as well as themulti-function mobile wallet described herein. In response, thefinancial institution, via an associated computing system, may implementan identification verification process. For example, the identificationverification process may include requesting a digital form (e.g., ascanned image) of required documentation (e.g., a driver's license,social security card, and the like) from the customer. Upon receipt ofthe digital form of the digital documentation, the financial institutioncomputing system may take steps/actions/etc. to verify the customer'sidentity. For example, the financial institution computing system mayaccess a database to obtain additional customer information andformulate a query (e.g., a security question) to transmit to thecustomer based on the obtained information. If the customer respondscorrectly to the query, an automated or largely automated credit cardapplication sequence may be initiated whereby a credit application islargely pre-populated using the information obtained from accessibledatabases and submitted by the customer. Once the application issubmitted, the financial institution computing system determines if thecustomer qualifies for a credit card and, if so, pre-underwrites thecustomer for a credit card account, creates a digital credit cardaccount for the customer, initiates a sequence to tokenize the digitalcredit account, and initiates a sequence to send the user a physicalcredit card in the mail. After this, the customer can view and activatethe digital credit card account from within the customer's new mobilewallet and have the digital credit card available for use within themobile wallet well before the physical credit card arrives. Thus, usingthe systems, methods, and computer-implementations described herein, afinancial institution customer can go from not having an account tohaving a functional account within a short amount of time (e.g., minutesor seconds) without ever having to enter a brick-and-mortar location ofthe financial institution.

Technically and beneficially, the systems, methods, and implementationsdisclosed herein improve the efficiency with which users can performvarious transactions. This is done through unique pairings of userinteractions with the mobile wallet and various other functionalities.Such pairings enable users to simultaneously communicate multiplefinancial preferences through a single interaction with a mobile wallet.For instance, a user may interact with a mobile wallet to select aparticular payment vehicle and, by doing so, indicate a preference toboth engage in a mobile wallet transaction using the selected paymentvehicle as well as view an account balance associated with the selectedpayment vehicle. Additionally, if the selected payment vehicle has beenpaired with a P2P payment platform through processes described herein,the user selection of the payment vehicle further indicates a userpreference for making a P2P payment. Thus, by including unique pairingsof user interactions with a mobile wallet interface with variousfunctionalities, the systems and methods disclosed herein create a novelfinancial communications platform from within a mobile wallet. Themobile wallet constitutes a starting point for a plurality of differentuser transactions that before have not been associated with a mobilewallet.

Further, the systems and methods disclosed herein improve mobile deviceperformance. To illustrate, compare two users who want to manage apayment account and perform a mobile wallet transaction using thataccount. The first user performs these functions using two differentapplications, while the second does so using the systems and methodsdisclosed herein. To manage the payment account, the first user wouldhave to activate a mobile banking application or web browser on a usermobile device, log in, and select the account. Next, to perform a mobilewallet transaction, the first user would need to close the mobilebanking application and open up a mobile wallet application, login, andselect an account. Such a process is burdensome on both the user and themobile device. In the previous example, the first user would need toactivate two different applications, remember two different sets oflogin credentials, and select the same account twice: once for eachrespective action that the user wishes to perform. This requires atleast six user interactions with the mobile device before the first useris put into a position to perform the desired actions. This number ofinteractions, in addition to the activation of two applications, puts aburden on the mobile device. For example, such a process may use arelatively large portion of the system memory of the mobile device,leading to slower processing speeds and more power consumption. Thesecond user, because the systems and methods disclosed herein are used,however, only needs to activate one application, input one set of logincredentials, and select the account once to be able to perform bothactions. Only three user interactions with the mobile device arenecessary to put the user in a position to perform both desired actions.Thus, the user will take less time to perform both actions and activatea smaller number of applications. As such, the processor of the mobiledevice is freed up to perform other operations more efficiently. Thus,the systems and methods disclosed herein unexpectedly leads to improvedmobile device performance while providing the user access to the same ormore functionalities.

Further, still referring to the example above, because the second userhas access to all of the functionalities disclosed herein within asingle application instance, only a single set of security credentialsneed be to be used. This means that the user will have input a smallernumber of passwords, PINs, and the like. As a result, more stringentauthentication credentials (e.g., biometric authentication, morestringent password requirements, and the like) may be used while stillrequiring fewer user interactions with the mobile device to perform thesame functions as in current systems. Further, since all thefunctionalities disclosed herein may be provided in the same applicationinstance, they can be secured in the same application domain with aheightened level of security due to there being less necessity forinter-application communications within the mobile device. Thus,unexpectedly, the systems and methods disclosed herein allow for betterprotection of sensitive user information.

As used herein, the term “payment-related service” refers to services,functions, or features provided by a financial institution or otherentity relating to payments, fund transfers, and other financialservices such as banking. Examples of payment-related services include,but are not limited to, banking functions such as viewing accountbalances, transferring funds from various accounts, setting accountsecurity preferences, and the like. Other examples of payment-relatedservices allow users to engage in other types of transactions such asP2P payments, purchasing products or services from various merchants,and the like. Thus, the term “payment-related service” should beinterpreted to include all of these examples, as well as any otherexample discussed in relation to this term herein.

As used herein, the term “field” refers to a portion of a user interfaceviewable by the user on a user mobile device. Any interface viewable ona mobile device display may include any number of fields. Fields may becompletely separate portions of the user interface or may be overlappingwith one another. Any field may contain any number of elements such asheaders, graphics, icon, information, and the like.

As used herein, the term “interaction point” refers to an element on auser interface on a user mobile device that the user can interact with(e.g., by pressing the screen in a position corresponding to theinteraction point or swiping the screen) to induce a responsive actionby the user mobile device (e.g., button(s), icon(s), switch(es),alpha-numeric text, hyperlinks, etc.). For example, the user mayinteract with one interaction point to cause the user mobile device topresent another user interface containing information different from theinterface initially containing the interaction point.

As used herein, the term “token” refers to a surrogate or proxy valuethat replaces an actual or real-value in association with certain itemssuch as payment cards, user information (e.g., name) and the like. Forexample, a personal account number (PAN) associated with a user paymentcard may be “tokenized” by generating a surrogate value for the PAN. Amapping process or function may be used to relate the token-to-actualvalue (e.g., PAN) in, e.g., a database, such as a “token vault”. The“token” may have many structures including purely numeric (e.g., a 16digit token, a 19 digit token, a 8 digit token, etc.) to an alphanumericvalue. Further, the “token” may include additional information than justthe proxy value. For example, the token may include informationregarding the expiration date of the token, an accompanying cryptogram,etc. Thus, those of ordinary skill in the art will appreciate the highconfigurability of the “token” (and associated elements) with all suchvariations intended to fall within the scope of the present disclosure.

As used herein, the term “payment vehicle” refers to any card, account,or any other currency-attached object, virtual file, or database fromwhich a user can transfer funds to another entity. Example paymentvehicles include bank accounts, (e.g., checking accounts and savingsaccounts), other user accounts (e.g., flexible spending accounts, IRAaccounts, health savings accounts, investment accounts, and the like),transaction cards (e.g., gift cards, credit cards, debit cards), andfinancial rewards (e.g., cash back, rewards points, and the like).

Referring now to FIG. 1 , a block diagram of a computer-implementedsystem 100 for providing a multi-functional mobile wallet is shown,according to an example embodiment. As shown, the system 100 includes auser mobile device 110 associated with a user, a financial institutioncomputing system 130 associated with a financial institution, a tokenservice provider computing system 140 associated with a token serviceprovider, a mobile wallet computing system 150 associated with a mobilewallet provider, and one or more third party computing systems 160associated with various third parties. The various systems and devicesmay be communicatively and operatively coupled through a network 170,which may include one or more of the Internet, cellular network, Wi-Fi,Wi-Max, a proprietary banking network, or any other type of wired orwireless network or a combination of wired and wireless networks. Asdescribed herein, the system 100 may be used to provide amulti-functional mobile wallet on the user mobile device 110.

Third party computing systems 160 are computing systems associated withvarious third parties. As used herein with respect to third partycomputing systems 160, “third parties” refer to entities that provideservices useable with the mobile wallet on the user mobile device. Whileconventionally these third parties provide their services independent ofthe mobile wallet, according to the present disclosure, the third-partyservices are implemented with, embodied with, or otherwise included withthe multi-function mobile wallet. The “services” may include, but arenot limited to payment-related services such as online shopping, P2Ppayments, search engines, product review services, issuer-specificfinancial rewards, social media accounts, security services, and thelike.

As such, the “third parties” may include merchants, financialinstitutions, social media institutions, and the like. Some thirdparties may provide payment-related services that users may utilize. Forexample, a particular third party may provide a network communicationsplatform that enables P2P payments over the network 170 (e.g., Venmo®,Zelle™, Dwolla®, Snapcash™, Circle Pay®, etc.). In some arrangements,the third parties may include various financial institutions thatprovide various payment-related services to various users (e.g., VisaCheckout®, alerts, coupons, account management services and the like).In some arrangements, third parties may include merchants that operatevarious shopping websites (e.g., Amazon®). In some arrangements, thirdparties may include mobile wallet providers (e.g., other than the mobilewallet provider associated with the mobile wallet computing system 150),that provide access to various mobile wallets (Apple Pay® or AndroidPay®).

Third party computing systems 160 include a third party accountmanagement circuit 162, a third party accounts database 164, anintegration circuit 166, and a third party network circuit 168 thatenables the third party computing system 160 to exchange data,information, values, and the like over the network 170. The third partyaccounts database 164 is structured to retrievably store userinformation relating to user relationships with the third party, and mayinclude non-transient data storage mediums (e.g., local disc orflash-based hard drives, local network servers, and the like) or remotedata storage facilities (e.g., cloud servers). Third party accountdatabase 164 may include information pertaining to user accounts withthe third party. The information stored in the third party accountdatabase 164 varies depending on the particular service provided by thethird party computing system 160.

The third party account management circuit 162 is structured to providethe user with access to the third party computing system 160 to manageone or more of their accounts. As will be appreciated, thefunctionalities performed by the third party account management circuit162 will vary depending on the nature of the service provided at thethird party computing system 160. In some embodiments, the third partyaccount management circuit 162 is configured to provide an application(e.g., a third party client application 116, described in greater detailbelow) on various user mobile devices 110. The application may provideusers with various displays enabling the users to take advantage of thevarious functionalities provided by the third party computing systems160.

The integration circuit 166 includes various software components thatare executable by a processor of the third party computing system 160 tofacilitate intercommunications with external computing systems (e.g.,mobile wallet computing system 150 and/or the user mobile device 110).For example, various APIs the integration circuit 166 may includevarious APIs that cause the third party computing system 160 to transferinformation to requesting parties such as the mobile wallet provider.

In some arrangements, the integration circuit 166 includes varioussoftware components (e.g., various SDKs), that facilitate, enable, orotherwise permit the third party to integrate various third partyfeatures, systems, or applications with applications provided by otherentities (e.g., the mobile wallet client application 112, describedbelow). To illustrate, the integration circuit 166 may include an SDKprovided by the mobile wallet provider. Such an SDK may be used by thethird parties to create software packages that may be integrated intothe mobile wallet client application 112 provided by the mobile walletprovider. The software packages may, for example, include widgetsincluding graphical control elements that can be integrated into amobile wallet interface presented to the user via the mobile walletclient application 112. Additionally or alternatively, the softwarepackages may include applets or containers that enable the mobile walletprovider to add third-party-specific functionalities to the mobilewallet client application 112. In some arrangements, the third partycomputing systems 160 may transfer these software packages to the mobilewallet computing system 150, which may integrate these software packagesinto the mobile wallet client application 112 to add third partyfunctionalities to the user's mobile wallet.

The mobile wallet computing system 150 is structured to permit, enable,facilitate, manage, process, and otherwise allow mobile wallettransactions. As used herein, the term “mobile wallet transaction” ismeant to be broadly interpreted to refer to transactions accomplishedvia the mobile wallet on the user mobile device. As such, the mobiletransaction may include, but is not limited to, a person-to-personpayment, a payment for a good or service at a point-of-sale terminal ofa merchant, etc. The mobile wallet computing system 150 may beassociated with, owned by, and/or otherwise operated by a mobile walletprovider. In one embodiment, the mobile wallet provider may be afinancial institution, such as the financial institution associated withthe financial institution computing system 130. In this instance, themobile wallet computing system 150 may be a part of the financialinstitution computing system 130. In another embodiment and as shown,the mobile wallet provider may be a third party provider relative to thefinancial institution that operates the financial institution computingsystem 130.

In any configuration, the mobile wallet computer system may provide orat least partly provide a mobile wallet circuit 154. As described inmore detail herein, the “mobile wallet” is a digital wallet provided onthe user mobile device 110. The digital wallet may include paymentcapabilities, such as the ability to use a communication protocol (e.g.,near-field communication) at a point-of-sale terminal to transferpayment information and enable the purchase of a good or service.Additionally, the digital wallet may include many other capabilities,functions, and features that are described herein in more detail.

In arrangements where the mobile wallet provider is the financialinstitution associated with the financial institution computing system130, each of the operations described herein with respect to the mobilewallet computing system 150 may also be described as being performed bythe same financial institution. In such arrangements, the financialinstitution computing system 130 and the mobile wallet computing system150 may be operated as a single computing system, or as two or moreseparate computing systems (as shown in FIG. 1 ) performing theassociated functions described herein. As will be appreciated, the levelof functionality that resides on the financial institution computingsystem 130 as opposed to the mobile wallet computing system 150 in thesearrangements may vary depending on the implementation.

With the above in mind, the mobile wallet computing system 150 is shownto include a mobile wallet database 152, a mobile wallet circuit 154,and a mobile wallet network circuit 156 enabling the mobile walletcomputing system 150 to exchange data over the network 170. In somearrangements, the mobile wallet computing system 150 also includes acustom credit approval circuit 138 that includes the various structuresand functionalities discussed below with respect to the financialinstitution computing system 130. As described herein, the mobile walletcomputing system 150 may be configured to exchange data with the mobiledevice 110, financial institution computing system 130, third partycomputing systems 160, and token service provider computing systems 140in the implementation of a user mobile wallet.

Mobile wallet database 152 is structured to store information regardingmobile wallet accounts held by various users, such as for a mobilewallet account held by the user of the user mobile device 110. Forinstance, the mobile wallet database 152 may store various forms ofinformation related to the user and/or an associated mobile device uponregistration of one or both for a mobile wallet. The stored mobilewallet account information may include authentication information (e.g.,username/password combinations, device authentication tokens, securityquestion answers, etc.), payment card information, and transactionhistory, account holder identifying information, registered deviceinformation, and any other information that may be encountered in theoperation of a mobile wallet account or otherwise referenced herein.Such information may include user preferences and other informationcomprising a user profile. In some arrangements, for example, mobilewallet database 152 also includes a token vault that is maintained bythe mobile wallet computing system 150. The token vault may include alookup table maintaining tokens associated with various user paymentvehicles. The tokens stored therein may be generated internally (e.g.,at the mobile wallet computing system 150) or by other entities (e.g.,the token service provider computing system 140). For example, in oneembodiment, the token vault may include a lookup table including tokensthat that have been randomly assigned to a user payment vehicle (e.g.,user lines of credit, user checking accounts, and the like) by themobile wallet computing system 150. In some arrangements, the mobilewallet computing system 150 may include an associated token managementsystem (not shown) including one or more algorithms, processes,formulas, etc. that facilitate the efficient searching of theinformation stored in the token vault. For example, a mapping algorithmmay be utilized to map Token-to-PAN information. Thus, when a token isreceived, the mapping algorithm determines the associated PAN and sendsthat information to the issuer. In some arrangements, the token vault isprovided at a computing system associated with a separate entity, suchas the token service provider computing system 140 described below.

The mobile wallet circuit 154 is structured to provide a mobile walleton the user mobile device 110. In some embodiments, the mobile walletcircuit 154 is structured to provide a mobile wallet client application(e.g., mobile wallet client application 112 discussed below) on the usermobile device 110. In this regard, the mobile wallet circuit 154 enablesregistrations of a user for a mobile wallet, presents the user withvarious user interfaces enabling user to use or manage a mobile wallet,and enables users to perform transactions using the mobile wallet. Amore detailed view of the mobile wallet circuit 154 will be describedbelow in relation to FIG. 2 .

The token service provider computing system 140 includes a computingsystem configured to provision payment credentials (e.g., paymenttokens) on behalf of a mobile wallet user. The token service providercomputing system 140 may be operated by a credit card network or othertype of payment system, an acquiring or issuing financial institution(e.g., financial institution computing system 130), a merchant, a mobilewallet provider (e.g., mobile wallet computing system 150), and/oranother provider. The token service provider computing system 140 isconfigured to communicate remotely with the other systems and devices ofsystem 100 via the network 170.

The token service provider computing system 140 may be configured tofacilitate various services associated with payment tokens, includingprovisioning (e.g., generating) new tokens, authorizing a token for usein a financial transaction, storing payment vehicle tokens (e.g., in atoken vault), and managing the life cycles of the payment vehicletokens. The token service provider computing system 140 may beconfigured to provision payment tokens in response to a request receivedfrom the mobile wallet computing system 150. For example, the mobilewallet computing system 150 may request that the token service providercomputing system 140 provision payment tokens for those payment vehicles(e.g., credit cards, debit cards, gift cards, and the like) selectedwhen the user is registered.

The financial institution computing system 130 is a computing system ata financial institution that provides and maintains one or morefinancial accounts (e.g., demand deposit account, credit or debit cardaccount, brokerage account, etc.) on behalf of the user. In somearrangements, the financial institution is an issuer of a paymentvehicle held by the user. The payment vehicle may be used as a sourcepayment vehicle for transactions engaged in via the user's mobilewallet. In the context of the present disclosure, the financialinstitution can include commercial or private banks, credit unions,investment brokerages, mobile wallet providers, and so on, but can alsoinclude any commercial entity capable of maintaining payment vehicles onbehalf of a user, including retailers, vendors, service providers, andthe like. In some arrangements, the financial institution is also amobile wallet provider configured to manage mobile wallet accounts onbehalf of its customers (i.e., users), including authenticating mobilewallet transactions involving debits from the users' payment vehicles.For example, the financial institution may also operate the mobilewallet computing system 150 in various embodiments.

The financial institution computing system 130 includes a financialinstitution network circuit 132 enabling the financial institutioncomputing system 130 to exchange data over the network 170, a financialinstitution accounts database 134, an account management circuit 136, acustom credit approval circuit 138, and an identity verification circuit139. In some arrangements, the financial institution computing system130 includes an integration circuit similar to the integration circuit166 discussed above in relation to the third party computing systems160. The integration circuit may, for example, include an API thatfacilitates the delivery of account information (e.g., account balanceinformation, an account transaction history, and the like) to the usermobile device 110. The financial institution accounts database 134 isstructured to retrievably store user information relating to the variousoperations discussed herein, and may include non-transient data storagemediums (e.g., local disc or flash-based hard drives, local networkservers, and the like) or remote data storage facilities (e.g., cloudservers). The accounts database 134 may include personal information(e.g., names, addresses, phone numbers, and so on), authenticationinformation (e.g., username/password combinations, device authenticationtokens, security question answers, unique customer identifiers,biometric data, etc.), and financial information (e.g., tokeninformation, account numbers, account balances, available credit, credithistory, transaction histories, and so on) relating to the various usersand associated financial accounts.

The account management circuit 136 is structured to manage the financialaccounts of various users, including maintaining and handlingtransaction processing for the user's one or more financial accounts. Insome embodiments, a banking client application on the user mobile device110 (e.g., as one of the third party client applications 116) isprovided by the account management circuit 136. In this regard, theaccount management circuit 136 is configured to provide interfaces,displays, and associated content to enable users to manage accounts atthe financial institution associated with the financial institutioncomputing system 130 via banking client application. In theseembodiments, the banking client application may be executed andmaintained remotely by the financial institution computing system 130.As will be appreciated, the level of functionality that resides on theuser mobile device 110 as opposed to the financial institution computingsystem 130 may vary depending on the implementation.

The identity verification circuit 139 is structured to verifyinformation received from a user in the registration process describedbelow. With regard to the end-to-end digital customer engagement processdescribed above, the identity verification circuit 139 obtainsinformation from various sources to authenticate a new user prior toinitiating an account application process. As described herein, theidentity verification circuit 139 utilizes a combination of what youhave and what you know verification process (e.g., a driver's license(what you have) plus a question (what you know)). In some arrangements,responsive to receiving a request from a new user to register for anaccount with the financial institution from the user mobile device 110over the network 170, the identity verification circuit 139 transmits afirst prompt to the user mobile device 110 requesting the user to takeimages of user identification documents required for the opening of anew financial account. The prompt may include a document-imaging buttonconfigured to activate a camera included on the user mobile device 110to enable the user to take images of the required documentation. Forexample, the prompt may instruct the user to take an image of both theback and the front of the user's driver's license. Additionally, theprompt may also instruct the user to capture an image of the user's faceand/or capture a live video of the user performing an action (e.g.,answering a question) to be transmitted to the financial institutioncomputing system 130. Additionally, this prompt or other prompts mayrequest the user to provide authorization for the financial institutionto contact the user's phone carrier for information pertaining to theuser mobile device 110 and/or user.

In various arrangements, once the user has captured images and/or videoof, for example, a driver's license as well as the user's face, theidentity verification circuit 139 may perform a multi-step process tovalidate the user's license. First, the identity verification circuit139 may determine the authenticity of the documentation imaged by theuser. In this regard, the identity verification circuit 139 may performan image comparison analysis between the image of the user's driver'slicense and a driver's license template. If any differences are foundbetween the imaged license and the template, the identity verificationcircuit 139 may transmit a denial notification to the user mobile device110. If, however, various features of the user driver license (e.g.,government seals, image dimensions, and the like) match those of thetemplate, the identity verification circuit 139 may move onto the nextvalidation step. In the next step, the identity verification circuit 139compares the image or live video of the user's face captured by the userto the image of the user on the user's driver's license. If the imagesmatch, then the identity verification circuit 139 may move ontoadditional verification steps. For example, the identity verificationcircuit 139 may extract various user attributes (e.g., name, address,and the like) from the image of the user's validated driver's license togenerate a user profile.

In some arrangements, using the generated profile, the identityverification circuit 139 formulates an information request. For example,in one embodiment, the identity verification circuit 139 uses theprofile to formulate a request for a report containing additional userinformation (e.g., past addresses, employment information, and the like)from an external service provider. In some arrangements, responsive toreceiving such a report, the identity verification circuit 139formulates a query to send to the user. For example, the identityverification circuit 139 may generate a prompt requesting the user toidentify a past employer and/or address. When the user's response isreceived, the identity verification circuit 139 compares the response tothe information contained in the report to verify the user.

In various arrangements, additional user identity verification processesmay be performed. For example, the identity verification circuit 139 maytransmit an information request to a third party or the user's mobiledevice carrier to verify the user mobile device 110 and other userinformation. For example, the user's mobile device carrier may provideuser information (e.g., phone number, name, and address) that can becross-referenced with the information extracted from the user's driver'slicense to provide a further point of verification. Additionally, in thecase where the user already has an account with the financialinstitution, information stored in the accounts database 134 may befurther used to verify the user's identity. Additionally, the identityverification circuit 139 may cross reference various user informationwith any government databases including, for example, informationidentifying known bad actors or the like. If the user passes all ofthese identity verification checkpoints, the identity verificationcircuit 139 may transmit a verification notification to, for example,the custom credit approval circuit 138 and/or mobile wallet circuit 154for use in an account activation procedure to be described below.

In some arrangements, the custom credit approval circuit 138 isstructured to pre-approve a financial institution customer that is alsoa mobile wallet user for an individually tailored credit card and allowthe user to activate the credit card via the user's mobile wallet. Insome arrangements, the custom credit approval circuit 138 may retrieveavailable information pertaining to a mobile wallet user. For example,the user may hold a checking account with the financial institution butnot hold a credit card account with the financial institution. Thecustom credit approval circuit 138 may access available informationpertaining to the user and pre-approve the user for a credit cardwithout being requested to do so by the user. In some arrangements, thecustomer credit approval circuit 138 is configured to pre-approve theuser based solely on information stored in the financial institutioncomputing system 130. Accordingly, the custom credit approval circuit138 is configured to access the financial institution accounts database134, and assess the information pertaining to the user againstpredetermined criteria (e.g., account balance thresholds, creditratings, age of the user's financial institution account, and the like)to determine the parameters of a credit card (e.g., interest rate,credit limit, and the like) to offer to the user.

In some arrangements, after a new user has been verified by the identityverification circuit 139 by the processes discussed above, the customcredit approval circuit 138 is configured to perform a process todetermine the new user's eligibility for a new payment account (e.g.,credit card account). For example, the custom credit approval circuit138 may assess the information contained in any of the informationobtained by the identity verification circuit 139 discussed aboveagainst predetermined criteria (e.g., account balance thresholds, agesof existing user credit accounts, timeliness of past user payments onprevious credit account, number of user credit inquiries, etc.) todetermine the parameters of a credit card (e.g., interest rate, creditlimit, and the like) to offer to the user.

In some arrangements, the custom credit approval circuit 138 isconfigured to generate a credit card that is customized for the mobilewallet user or new user. In this regard, the custom credit approvalcircuit 138 determines at least one user credit preference based onavailable information pertaining to the user. In some arrangements, usercredit preferences include a balance transfer preference. To illustrate,a particular mobile wallet user may have a checking account at thefinancial institution, and a credit card at another financialinstitution. The user may use the checking accounts to make payments onthe credit card, and a record of such payments may be stored in thefinancial institution accounts database. Based this stored information,or information contained in a credit report received from a creditbureau, the custom credit approval circuit 138 may offer to transfer thebalance of the user's old credit card to the new credit card associatedwith the offer at a particular interest rate over a particular timeperiod (e.g., 0% APR for 18 months).

In some arrangements, the user preference includes determining a type offinancial rewards program to be associated with the offered credit card.For example, based on transaction history information stored in thefinancial institution accounts database 134, the customer creditapproval circuit 138 may identify a merchant (or set of merchants) thatthe user prefers to shop at and generate a credit card that rewards theuser for shopping at that particular merchant (e.g., two-percent cashback at all times at those identified merchants whereas all otherpurchases only receive one-percent cash back). Thus, this type of actionmay even entice the user into signing-up for the credit card.Alternatively, the reward may be based on the user's financialinformation. For example, if the custom credit approval circuit 138determines that the user is paying off a mortgage, a mortgage rewardscredit card may be offered to the customer.

In some arrangements, the custom credit approval circuit 138 isconfigured to access additional sources (e.g., third party computingsystems 160) of information to gather user data. For example, during theregistration process for a mobile wallet (to be described in greaterdetail below), the user may be asked to provide social media logincredentials so that the social media platform maybe integrated into theuser's mobile wallet via the methods discussed herein. The mobile walletcomputing system 150 may (e.g., via an API), access information storedon a social media platform pertaining to the user, and provide theinformation to the custom credit approval circuit 138. The custom creditapproval circuit 138 may include algorithms for comparing the receivedsocial media information to the information stored in the financialaccounts database 134 or information received from other verifiedsources to determine the legitimacy of the social media information. Ifthe social media information is determined to be legitimate, the socialmedia information may be used in determining a user credit preference tocustomize the credit card offer. Similar processes may be performed toobtain other types of information pertaining to the user (e.g., usersearch engine information or user purchasing preferences at an onlinemerchant). In various arrangements, the custom credit approval circuit138 is configured to assess all information pertaining to the user fromthird parties to generate at least one customer credit preference usingmethods similar to those discussed above.

In some arrangements, the custom credit approval circuit 138 isconfigured to generate a graphical representation of the preapprovedcredit card offer to be presented to the user via the user's mobilewallet. The graphical presentation may be encoded with hypertext thatfacilitates the user communicating acceptance of the credit card offerwith the financial institution computing system 130 over the network170. In some arrangements, the custom credit approval circuit 138 isconfigured to transmit the generated graphical presentation to themobile wallet computing system 150 over the network 170. In somearrangements, the financial institution computing system 130 isconfigured transmit the credit card offer directly to the user mobiledevice 110 such that the offer is viewable by the user via the user'smobile wallet, as described below.

The user mobile device 110 is a mobile device associated with a mobilewallet user. The user may include one or more individuals, businessentities, government entities, and agents. The user mobile device 110 isstructured to exchange data over the network 170, execute softwareapplications, access websites, generate graphical user interfaces, andperform other operations described herein. The user mobile device 110may include one or more of a smartphone or other cellular device, awearable computing device (e.g., eyewear, a watch or bracelet, etc.), atablet, a portable gaming device, a laptop, and other portable computingdevices.

The user mobile device 110 includes a mobile wallet client application112, third party client applications 116, a user input/output (“I/O”)device 118, and a mobile device network circuit 120 enabling the usermobile device to exchange information over the network 170. The user I/Odevice 118 includes hardware and associated logics configured to enablethe mobile device 110 to exchange information with a user and otherdevices (e.g., a merchant transaction terminal). An input aspect of theuser I/O device 118 allows the user to provide information to the mobiledevice 110, and may include, for example, a mechanical keyboard, atouchscreen, a microphone, a camera, a fingerprint scanner, any userinput device engageable to the mobile device 110 via a USB, serialcable, Ethernet cable, and so on. An output aspect of the user I/Odevice 118 allows the user to receive information from the mobile device110, and may include, for example, a digital display, a speaker,illuminating icons, LEDs, and so on. The user I/O device 118 may includesystems, components, devices, and apparatuses that serve both input andoutput functions, allowing the financial institution computing system130 exchange information with the mobile device 110. Such systems,components, devices and apparatuses include, for example, radiofrequency transceivers (e.g., RF or NFC-based transceivers) and othershort range wireless transceivers (e.g., Bluetooth®, laser-based datatransmitters, etc.).

The mobile device 110 further includes a mobile wallet clientapplication 112. The mobile wallet client application 112 is structuredto facilitate and permit payments by interfacing with various accountsheld by the user at various financial institutions (e.g., the financialinstitution associated with the financial institution computing system130 and/or other financial institutions). Accordingly, in somearrangements, the mobile wallet client application 112 is communicablycoupled via the network circuit 120 over the network 170 to the mobilewallet computing system 150. In some embodiments, the mobile walletclient application 112 includes a circuit embodied within the usermobile device 110. For example, the mobile wallet client application mayinclude program logic stored in a system memory of the user mobiledevice 110. In such arrangements, the program logic may configure aprocessor of the user mobile device to perform at least some of thefunctions discussed above with respect to the mobile wallet circuit 154of the mobile wallet computing system 150. In some embodiments, themobile wallet client application is a web-based application, and many ofthe functionalities are provided at the mobile wallet circuit 154 of themobile wallet computing system 150. As will be understood, the level offunctionality that resides on the user mobile device 110 versus themobile wallet computing system 150 will vary depending on theimplementation.

In various arrangements, the mobile wallet client application 112 isstructured to permit mobile wallet users to engage in transactionsthrough the initiation of communications with, for example, a merchantpoint of sale device. In this regard, the mobile device 110 may includea near field communications (NFC) chip and an associated controller thatconfigures the chip to exchange information with the merchant point ofsale device (e.g., an NFC reader). It should be understood that the rolethat the mobile wallet client application 112 takes in paymenttransactions will depend on the implementation of the mobile wallet. Insome arrangements, for example, the mobile wallet is implemented in asecure element framework. In such arrangements, the user mobile device110 includes a secure element that is separate from the main systemmemory of the user mobile device. The secure element may include anyelement having smart card functionalities, such as a universalsubscriber identity circuit (a SIM card) or a secure digital card. Insuch arrangements, user authentication information (e.g., paymentvehicle information, user PINS, and the like) is stored in the secureelement. In various arrangements, the secure element of the mobiledevice 110 may include a payment application that interfaces with theNFC chip of the user device responsive to receiving a communication(e.g., an application protocol data unit) from the merchant point ofsale device to enable user payment information be transferred. In sucharrangements, no user information is transferred by the mobile walletclient application 112 to the NFC chip. After user payment informationis transmitted to the merchant point of sale device, the mobile walletclient application 112 may query the secure element for transaction datato notify the user of the completed transaction.

In other arrangements, the mobile wallet client application 112 mayoperate under a host card emulation framework. In such arrangements,user payment information is maintained within the mobile wallet clientapplication 112 or cloud-based environment (e.g., a host emulationservice or the mobile wallet database 152) rather than in the secureelement. In this regard, the mobile wallet client application 112 mayinclude a service component (e.g., a payment application) configured tointerface with the NFC chip of the mobile device 110 to communicate userpayment tokens to the merchant point of sale device. To ensure securityof user information, the mobile wallet client application 112 mayinclude sandboxing functionalities where a unique user ID (UID) isassigned to the mobile wallet client application 112, and where onlyother applications (e.g., third party client applications 116) includingthe same UID may share information stored in relation to the mobilewallet client application 112.

In various other arrangements, the user-specific payment information maybe stored in a trusted execution environment (“TEE”) within a processorthe user mobile device 110. The systems and methods disclosed herein mayalso be used with other modalities currently available for storage andtransfer of user payment device via contactless communicationmechanisms.

In some arrangements, the mobile wallet client application 112 isstructured to enable the user to manage a mobile wallet. In this regard,the mobile wallet client application 112 is structured to present,control, and otherwise manage displays or graphical user interfaces onthe mobile device 110 including information pertaining to variouspayment vehicles. For example, the mobile wallet client application 112may present the user with displays enabling the user to inputinformation pertaining to various payment vehicles. The screens mayenable the user to manually input information (e.g., a PAN) pertainingto a payment vehicle, or enable the user to take a picture of a paymentvehicle. The mobile wallet client application 112 may then process theinformation input by the user, identify account information, andtransmit the information to the mobile wallet computing system 150 forstorage (e.g., in the mobile wallet database 152 in association with theuser). Once information pertaining to various payment vehicles has beenreceived by the mobile wallet computing system 150, the mobile walletclient application 112 is configured to present displays that enable theuser to select a payment vehicle from amongst a plurality of paymentvehicles. Once a payment vehicle is selected, the displays may furtherenable the user to perform various actions using the selected paymentvehicle (e.g., use the selected vehicle to complete a mobile wallettransaction, manage an account at a financial institution associatedwith the selected payment vehicle, view a transaction history associatedwith the payment vehicle, and the like).

In various arrangements, the displays presented to the user by themobile wallet client application 112 further enable the user to takeadvantage of other payment-related services (e.g., services other thanthose discussed above). In one embodiment, the displays includegraphical depictions of various services other than the mobile wallet(e.g., payment-related services such as a mobile shopping application).The services depicted may bear certain relationships to the paymentvehicles presented on the mobile wallet interface. One example relatesto a P2P payment service. In such an example, if the user's mobilewallet interface includes a debit card, the interface may include adepiction of the P2P payment service. However, if the user's mobilewallet interface includes a credit card, the interface may not include adepiction of the P2P payment service because most P2P services do notallow use of credit cards.

In various arrangements, the payment-related services included in themobile wallet interface may both be internal services offered by themobile wallet provider (and an associated financial institution such asthe financial institution associated with the financial institutioncomputing system 130) as well as external services offered by variousthird parties. With regard to internal services, the mobile walletinterface may include depictions of account management functions (e.g.,viewing transaction histories, viewing account balances, managingaccounts, managing security settings, etc.). With regard to externalservices, the mobile wallet interface may include depictions of variousfunctionalities that enable the user to utilize various payment vehiclesin the context of various other payment-related services not directlyrelated to account management (e.g., mobile shopping applications,driving service applications, financial rewards applications, alerts,and the like). It should be understood that the mobile wallet providerand/or financial institution may also develop such functionalitieswithin the scope of the systems and methods herein.

In some arrangements, if a user selects a graphical depiction of aparticular payment-related service, the mobile wallet client application112 is structured to present the user with further displays enabling theuser to take actions with respect to that payment-related service (e.g.,to set up an account with the payment related service or to setparameters of an account). In some arrangements, responsive to a usersetting preferences pertaining to a payment-related service, the mobilewallet client application 112 is configured to communicate thosepreferences to the entity providing that service. In this regard, insome arrangements, the mobile wallet client application 112 includes athird party integration circuit 114. Third party integration circuit 114may include program logic that facilitates the communication of themobile wallet client application 112 with other entities (e.g., thirdparty computing systems 160). For example, third party integrationcircuit 114 may include various APIs that configure the mobile device110 to communicate information to the third party computing systems 160offering various payment-related services to the user via various thirdparty client applications 116 over the network 170.

To illustrate, if the selected payment-related service is a mobileshopping application associated with a particular merchant, the mobilewallet client application 112 may further present the user with adisplay that includes a plurality of products offered by the merchant.The user may be able to select a product and select a payment vehicle,and the mobile wallet client application 112 may configure the usermobile device 110 to transmit a purchase request to the third partycomputing system 160 associated with the merchant. In another example,if the selected payment-related service is a driving service application(e.g., Uber® or Lyft®), the mobile wallet client application 112 maypresent the user with a display enabling the user to set a location tobe driven to and/or a pickup time, and a payment vehicle to pay for theride. The mobile wallet client application 112 may cause the user mobiledevice 110 to transmit a ride request to the third party computingsystem 160 associated with the driving service. Thus, the mobile walletclient application 112 enables the user to take advantage of a pluralityof services related to payment vehicles provisioned to a mobile wallet,without ever leaving the mobile wallet client application 112.

Third party client applications 116 are structured to provide the userwith access to services offered by various third parties. In somearrangements, the third party client applications 116 are hard codedonto the memory of the mobile device 110. In another embodiment, theseapplications are web-based interface applications, where the user has tolog onto or access the web-based interface before usage, and theseapplications are supported by a separate computing system comprising oneor more servers, processors, network interface circuits, or the like(e.g., third party computing systems 160), that transmit theapplications for use to the mobile device.

In some arrangements, the third party client applications 116 arestructured to permit management of at least one user account associatedwith a third party service. Accordingly, a particular third party clientapplication 116 may be communicably coupled to a third party computingsystem 160 (e.g., the third party accounts database 164) via the network170. Through this communicative coupling, the third party computingsystem 160 (e.g., via the third party account management circuit 162)may provide displays regarding the particular third party service orapplication (e.g., account balance information). In variousarrangements, such information received by third party clientapplications 116 may be shared with the mobile wallet client application112 through the third party integration circuit 114 to facilitate theintegration of various functionalities into the mobile wallet clientapplication 112.

Referring now to FIG. 2 , a more detailed embodiment of the mobilewallet circuit 154 of the mobile wallet computing system 150 of thesystem 100 in FIG. 1 is shown. In some arrangements, the mobile walletcircuit 154 includes a function integration circuit 210, a userinterface management circuit 220, a registration circuit 230, and apayment processing circuit 240. Each of the circuits may be communicablyand operatively coupled to each other. Other embodiments may includeless or more circuits without departing from the spirit and scope of thepresent disclosure. Further, some embodiments may combine the activitiesof one circuit with another circuit to form a single circuit. Therefore,those of ordinary skill in the art will appreciate that the presentarrangement is not meant to be limiting.

In one configuration, the mobile wallet circuit 154 and associatedcircuits 210-240 are embodied as machine or computer-readable media thatis executable by a processor of the mobile wallet computing system. Asdescribed herein amongst other uses, the machine-readable mediafacilitates performance of certain operations to enable reception andtransmission of data. For example, the machine-readable media mayprovide an instruction (e.g., command, etc.) to, e.g., acquire data. Inthis regard, the machine-readable media may include programmable logicthat defines the frequency of acquisition of the data (or, transmissionof the data). Thus, the computer readable media may include code, whichmay be written in any programming language including, but not limitedto, Java or the like and any conventional procedural programminglanguages, such as the “C” programming language or similar programminglanguages. The computer readable program code may be executed on oneprocessor or multiple remote processors. In the latter scenario, theremote processors may be connected to each other through any type ofnetwork (e.g., CAN bus, etc.).

In another configuration, the mobile wallet circuit 154 and associatedcircuits 210-240 are embodied as hardware units, such as electroniccontrol units. As such, the mobile wallet circuit 154 and associatedcircuits 210-240 may be embodied as one or more circuitry componentsincluding, but not limited to, processing circuitry, network interfaces,peripheral devices, input devices, output devices, sensors, etc. In someembodiments, the mobile wallet circuit 154 and associated circuits210-240 may take the form of one or more analog circuits, electroniccircuits (e.g., integrated circuits (IC), discrete circuits, system on achip (SOCs) circuits, microcontrollers, etc.), telecommunicationcircuits, hybrid circuits, and any other type of “circuit.” In thisregard, the mobile wallet circuit 154 and associated circuits 210-240may include any type of component for accomplishing or facilitatingachievement of the operations described herein. For example, a circuitas described herein may include one or more transistors, logic gates(e.g., NAND, AND, NOR, OR, XOR, NOT, XNOR, etc.), resistors,multiplexers, registers, capacitors, inductors, diodes, wiring, and soon). Thus, the mobile wallet circuit 154 and associated circuits 210-240may also include programmable hardware devices such as fieldprogrammable gate arrays, programmable array logic, programmable logicdevices or the like. In this regard, the mobile wallet circuit 154 andassociated circuits 210-240 may include one or more memory devices forstoring instructions that are executable by the processor(s) of themobile wallet circuit 154 and associated circuits 210-240. Thus, in thishardware unit configuration, the mobile wallet circuit 154 andassociated circuits 210-240 may be geographically dispersed from oneanother. Alternatively and as shown, the mobile wallet circuit 154 andassociated circuits 210-240 may be embodied in or within a singleunit/housing, which is shown as the mobile wallet circuit 154.

Function integration circuit 210 may be program logic that configuresthe mobile wallet circuit 154 to integrate payment-relatedfunctionalities into a user's mobile wallet. In some arrangements,function integration circuit 210 includes a series of software elementsthat provide accessibility to various functionalities discussed herein.In this regard, the function integration circuit 210 may include aplurality of sets of program logic associated with variousfunctionalities developed by the mobile wallet provider and/or financialinstitution associated with the financial institution computing system130. Such functionalities may enable the user to perform variousoperations with respect to various user payment vehicles (e.g., managean account maintained by the financial institution computing system 130,view an account balance, view a transaction history, and the like).Further, such functionalities may also enable the user to performvarious types of transactions using various payment vehicles. Forexample, the function integration circuit 210 may include a widget thatprovides the user with access to a P2P payment platform. The widget maybe associated with a graphical element (e.g., an icon depicting the P2Ppayment platform) that may appear on the user's mobile wallet interfaceas will be described below. The icon may be coupled to program logicsuch that, upon the user's selection of the icon, the user is brought toa P2P transaction interface enabling the user to designate an intendedrecipient of funds and a transfer amount. In another example, anotherfunctionality may enable the user to access various financial rewardsassociated with various payment vehicles.

In some arrangements, the function integration circuit 210 may alsoinclude sets of program logic associated with various functionalitiesdeveloped by various third parties associated with third party computingsystems 160. For example, the function integration circuit 210 mayinclude various software integration packages. The integration packagesmay include program logic (e.g., an API or widget) that causes the usermobile device 110 to perform various operations (e.g., communicate withthe third party computing system 160 over the network 170) to provide aservice to the user. Additionally, the integration packages may includeassociated sets of user interface parameters that may be compatible witha user interface template provided by the mobile wallet provider. Forexample, the interface parameters may be structured to incorporate of adepiction (e.g., a graphical icon) of the functionalities that theintegration package is configured to add to the user's mobile walletinto the user's mobile wallet interface. The depiction may be coupled tothe program logic included in the integration package. For example, aparticular integration package may include a widget associated withgraphical representation of a third party P2P payments platform (e.g.,Venmo®, or PayPal®). The graphical representation may be coupled toassociated widget program logic such that, upon a user's selection ofthe graphical representation, the user is brought to an additionalinterface configured to receive various user inputs with respect to thethird party P2P payments platform to be communicated to the third partycomputing system 160.

User interface management circuit 220 is structured or configured togenerate, update, control or otherwise manage displays/graphical userinterfaces of the mobile wallet. In various arrangements, user interfacemanagement circuit 220 updates the displays responsive to various userinteractions with various portions of a mobile wallet interfacepresented to the user. For example, the user may indicate a preferenceto integrate a particular payment-related service or functionality intothe user mobile device 110, and the user interface management circuit210 may update user interface parameters to incorporate a depiction ofthe requested service or functionality in an updated version of themobile wallet client application 112. In some arrangements, the userinterface management circuit 220 updates displays viewable by the userresponsive to information received from the financial institutioncomputing system 130. For example, responsive to receiving updatedaccount balance information or a credit card offer from the financialinstitution computing system 130, the user interface management circuit220 may update the user interface parameters associated with the mobilewallet client application 112 to incorporate the balance information andoffer.

The registration circuit 230 may perform a registration process toprovide a first time mobile wallet user with a mobile wallet. In thisregard, the registration circuit 230 may present the user with aplurality of registration interfaces (e.g., viewable by a web browser onthe user mobile device 110) prompting the first time user to inputinformation such as payment vehicle information, user identifyinginformation, login credentials, and the like). As discussed above, theregistration interfaces may also ask the user permission to access usersocial media data (e.g., maintained in the user mobile device via athird party client application or a third party computing system 160)and other data.

Further, with respect to the end-to-end digital user engagementexperience discussed above, the registration circuit 230 may alsoperform various steps to register a new user for a new payment account(e.g., a credit card) with the financial institution. In this regard,the registration circuit 230 may operate in concert with the identityverification circuit 139 discussed above. For example, if a particularnew user wishes to register for a new account without visiting abrick-and-mortar location associated with the financial institution, theregistration circuit 230 may present the user with various promptsinstructing the user to capture images of required documentation (e.g.,a driver's license). Further, if the identity verification circuit 139validates the new user via the processes discussed above, theregistration circuit 230 may further present the user with a cardapplication interface requesting information from the user. Theapplication interface may include several fields requesting variousforms of information (e.g., name, address, social security number, andthe like) from the user. In some arrangements, a subset of the fieldsincluded on the application interface is pre-populated with informationreceived from the identity verification circuit 139. For example, theapplication interface may pre-populate a user name field withinformation gathered from the captured images of the requireddocumentation. Other fields may be pre-populated using informationcontained in a credit report or other information from public databasereceived by the identity verification circuit 139.

Based on the information received from the user and the information fromvarious other sources, the registration circuit 230 may determine theelements to include in various user mobile wallet interfaces. Forexample, the registration circuit 230 may use the payment vehicleinformation received from the user to identify the financialinstitutions associated with the payment vehicles that the user wishesto add to the mobile wallet (e.g., based on the format or numericalsequence of a PAN). Additionally, the registration circuit 230 maycommunicate user data to the financial institution computing system 130to identify other payment accounts associated with the user. Based onthis determined information, the registration circuit 230 may transmitinstructions to the user interface management circuit 220 as to variousgraphical depictions of various payment vehicles to include on the usermobile wallet interfaces.

Additionally, the registration circuit 230 may use the availableinformation pertaining to the user to identify a set of payment-relatedservices that is most applicable to the user based on availableinformation. For example, the mobile wallet circuit 154 may assess theuser information to generate a profile describing various aspects of theuser. The profile may, for example, describe an operating system type ofuser mobile device 110 (e.g., Android®, iOS®, and any other type ofplatform), the identity of various financial institutions at which theuser has accounts, the types of accounts (e.g., checking, savings, giftcards, credit) that the user wishes to provision to the mobile wallet,transaction history/spending habits of the user (e.g., if the userrepeatedly spends more than $100 at a particular store each month,physical locations of merchants that the user frequently visits, etc.),and user preferences as to the type of payment-related services that theuser would like to have available via the mobile wallet.

Based on the user profile, the registration circuit 230 identifies a setof services to make accessible via the user's mobile wallet. Forexample, if the user's profile reveals a user preference for shopping ata particular merchant, the registration engine may determine if thefunction integration circuit 210 includes an integration packageassociated with that merchant. If so, the registration circuit 230 mayinstruct the user interface management circuit 220 to include an iconassociated with the package in the user's mobile wallet interfaces. Inanother example, if the user's profile indicates a user preference toonly provision a single rewards credit card, the registration circuit230 may instruct the user interface management circuit 220 to include anicon representing a widget enabling the user to view the rewards thatthe user has earned using the rewards credit card.

The payment processing circuit 240 is structured to process user paymentrequests. For example, the user may indicate a preference to engage in amobile wallet transaction using a payment vehicle. The mobile walletclient application 112 provided on the user mobile device 110 may thentransmit transaction information, a token, and any other paymentinformation or security information (e.g., a cryptogram) to a merchant,which may then transmit the token and the aforementioned describedinformation to the mobile wallet computing system 150. The mobile walletcircuit 154 may receive this information and either de-tokenize thetoken or transmit the token to the token service provider computingsystem 140 for de-tokenization. Once the token is de-tokenized, themobile wallet circuit 154 may identify the financial institutionassociated with the payment vehicle and transmit the transactioninformation to the financial institution computing system 130, which mayauthorize the transaction request. In response to receiving anauthorization from the financial institution computing system 130, themobile wallet circuit 154 may transmit an authorization to the merchantover the network 170, which may enable the user to complete the desiredtransaction. As will be appreciated, the role that the paymentprocessing circuit 240 serves in user mobile wallet transactions mayvary depending on the implementation of the user's mobile wallet. Forexample, in arrangements where the user's mobile wallet operates under ahost emulation framework, the payment processing circuit 240 maytransmit user payment information (e.g., tokens) to the user mobiledevice 110 to enable the user to initiate a mobile wallet transaction.On the other hand, in arrangements where the mobile wallet isimplemented in a secure element framework, the payment processingcircuit 240 may not perform such functions.

Referring now to FIG. 3 , a flow diagram of a method 300 of registeringa customer for a mobile wallet according to an example embodiment isshown. The method 300 may be performed by the components of FIGS. 1 and2 , such that reference may be made to one or more components of FIGS. 1and 2 to aid description of the method 300.

At process 302, a user request to register for a mobile wallet isreceived. In some arrangements, the request is received from the usermobile device 110. For example, the user may access a website associatedwith the mobile wallet provider, and indicate a preference to registerfor the mobile wallet. In other arrangements, such as where the mobilewallet computing system 150 is integrated into the financial institutioncomputing system 130, the registration request may be received from acomputing system associated with the financial institution. For example,a user my enter into a brick-and-mortar location associated with afinancial institution, and sign up for an account with the assistance ofa financial institution employee.

At process 304, the user is presented with one or more registrationinterfaces. In various arrangements, the mobile wallet circuit 154transmits registration interfaces to the computing device that theregistration preference was received from (e.g., the user mobile device110 or the financial institution computing system 130) over the network170. The registration interfaces may request various forms ofinformation from the user. For example, one registration interface mayprompt the user to establish login credentials (e.g., a username andpassword) for the mobile wallet. Another registration interface mayprompt the user to input information that can be used to authenticatethe user. For example, a registration interface may ask the user toinput information pertaining to a payment vehicle that the user wishesto provision to the mobile wallet and authentication credentials (e.g.,an address or PIN) that can be used to authenticate the user. Otherregistration interfaces may prompt the user to input informationpertaining to payment vehicles (e.g., accounts, gift cards, creditcards, and the like) that the user wishes to provision to the mobilewallet. Another registration interface may prompt a new mobile walletuser to indicate a preference to activate a new payment account (e.g., acredit card) with the financial institution. In some arrangements,responsive to the new mobile wallet user indicating such a preference,another registration interface may prompt the user to take captureimages of identification and/or other documentation required toestablish a payment account at the financial institution.

At process 306, user registration information is received. In somearrangements, the user inputs the information requested by theregistration interfaces into the user mobile device 110 (e.g., via theuser I/O device 118), which transmits the user-input information via thenetwork circuit 120 to the mobile wallet computing system 150.Alternatively, the information is input by personnel associated with thefinancial institution at the financial institution computing system 130.

At process 308, the user is authenticated. In some arrangements, where,for example, the mobile wallet computing system 150 is associated withthe financial institution computing system 130, the mobile walletcircuit 154 receives the authentication information received at process306 (e.g., an account number and authentication information), accesses adatabase (e.g., the financial institution accounts database 134) toretrieve verified user authentication information, and compares thereceived authentication information with the verified authenticationinformation. If the received data matches the verified data, the user isauthenticated. In some arrangements, where, for example, the mobilewallet computing system 150 is not associated with the financialinstitution computing system 130, the mobile wallet circuit 154 mayinitiate communications with external computing devices to authenticatethe user. For example, responsive to receiving the identity of a userfinancial account, the mobile wallet circuit 154 (e.g., via the functionintegration circuit 210) may identify a financial institution associatedwith the account and request authentication information pertaining tothe user from the financial institution computing system 130 via thenetwork 170 to authenticate the user.

In some arrangements, if, for example, the user is a new mobile walletuser that indicated a preference to sign up for a new payment account atprocess 306, the mobile wallet circuit 154 may communicate with theidentity verification circuit 139 discussed above to verify the newmobile wallet user's identity. For example, the mobile wallet circuit154 may transmit any scanned images received at process 306 to theidentity verification circuit 139 for further processing.

At process 310, a mobile wallet client application 112 is provided tothe user mobile device 110. In some arrangements, the mobile walletcircuit 154 may first identify the type and version of operating systemon the user mobile device 110 (e.g., iOS® v. Android®) based on theformat of a hypertext transfer protocol request received from the usermobile device 110 at any of the processes 302-306, for example. Based onthe identified mobile device type, the mobile wallet circuit 154 maytransmit a set of program logic to the user mobile device 110 over thenetwork 170 that is compatible with the user mobile device 110. Whilesome aspects of the mobile wallet client application 112 may beimplemented at the mobile wallet computing system 150, other aspects maybe hard coded into the memory of the user mobile device 110. Thus, anyor all of the elements of the mobile wallet circuit 154 discussed above(e.g., a function integration circuit 210, a user interface managementcircuit 220, a registration circuit 230, and/or a payment processingcircuit 240) may be transmitted to the user mobile device 110. As such,the mobile wallet client application 112 transmitted to the user mobiledevice 110 may configure the user mobile device 110 to perform any ofthe functions discussed above. Additionally, the transmitted mobilewallet client application 112 may include additional program logicsconfigured to interface with existing elements of the user mobile device110. For example, one element may enable the mobile wallet clientapplication 112 to interact with a camera or GPS locator deviceassociated with the user mobile device 110. Another element may providethe mobile wallet client application 112 access to information relatingto various third party applications 112 on the user mobile device (e.g.,a social media application).

In some arrangements, the mobile wallet circuit 154 (or the entity, suchas an app store or mobile wallet provider, through which a userdownloads the app) also assigns a unique identifier for specific mobilewallet client application 112 transmitted to the user mobile device 110.This unique identifier may be communicated to a push notificationservice, as well as other entities (e.g., the financial institutionassociated with the financial institution computing system 130) tofacilitate further processes discussed below.

At process 312, additional user information is retrieved. In variousarrangements, after the mobile wallet client application 112 istransmitted to the user mobile device 110, the initiation process forthe user's mobile wallet continues. For example, the user may activatethe mobile wallet client application for the first time and be promptedto provide permission for access to other forms of information (e.g.,user social media information). Upon receiving such permissions, themobile wallet circuit 154 may request and receive such information fromvarious third party computing systems 160 and/or user mobile device 110.Additionally, for existing account holders, the mobile wallet circuit154 (e.g., at the mobile computing system 150) may retrieve allavailable information pertaining to the user stored in the financialinstitution accounts database 134. Additionally, if, for example, theregistration information received from the user at process 306identifies additional payment vehicles associated with additionalfinancial institutions, the mobile wallet circuit 154 may identify thefinancial institutions associated with the additional payment vehiclesand request information pertaining to the user from the financialinstitution computing systems 130 associated with the financialinstitutions.

At process 314, services applicable to the user are identified. Invarious embodiments, the mobile wallet circuit 154 (e.g., via theregistration circuit 230) assesses the information pertaining to thecustomer received at any of the processes 302-310 using predeterminedcriteria to generate a user profile such as those discussed above. Forexample, based on a payment vehicle PAN entered by the user in theregistration interfaces presented to the user at 304, the mobile walletcircuit 154 may identify a payment vehicle type (e.g., a credit card,debit card, gift card, checking account, or the like), and a financialinstitution associated with the payment vehicle. Next, the mobile walletcircuit 154 identifies a set of services compatible with thoseidentified characteristics. For example, some payment-related services(e.g., P2P payment services) may not be compatible with credit cards.Accordingly, if the user only wishes to provision credit cards to themobile wallet, the mobile wallet circuit 154 may identify thecredit-incompatible services as being inapplicable to the user. Inanother example, if the user only wishes to provision debit cards to themobile wallet, certain integration packages associated with financialreward programs may be eliminated.

In some arrangements, after the mobile wallet circuit 154 has ruled outvarious incompatible services based on the characteristics of userpayment vehicles and the user mobile device 110, the mobile walletcircuit 154 is configured to select a subset of compatible services thatis most applicable to the user. For example, if a user transactionhistory indicates that the user has a tendency to over-draw a checkingaccount, the registration circuit 230 may select an account balancealert widget provided by the financial institution to incorporate intothe user's mobile wallet interfaces. This way, the user may be notifiedof a low account balance each time the user activates the mobile walletclient application. In another example, if, for example, social mediainformation reveals that the user frequently posts about traveling, anintegration package associated with travel-booking service (e.g.,Kayak®, Travelocity®, and the like) may be selected.

In some arrangements, the mobile wallet circuit 154 determines thesubset of compatible services using a statistical data comparison ofavailable information pertaining to the user with other user data. Forexample, the registration circuit 230 may compare the user's profileincluding the user's transaction history with that of a plurality ofother mobile wallet users to generate a group of other mobile walletusers having statistically similar to the user. Based on historicalmobile wallet service usage data (e.g., stored in the mobile walletdatabase 152) of the statistically similar users, the registrationcircuit determines a subset of services that are most commonly usedamong that group for the user.

At process 316, the user's mobile wallet interfaces are configured. Forexample, in some arrangements, after the mobile wallet circuit 154 ofthe mobile wallet computing system 150 identifies the set of services,the mobile wallet circuit 154 (e.g., via the user interface managementcircuit 220) generates a set of user interface parameters to transmit tothe user mobile device 110. The user interface parameters may compriseinstructions that are executable by the processor of the user mobiledevice 110 that configure the user mobile device 110 to present the userwith a customized set of mobile wallet interfaces upon user activationof the mobile wallet client application 112. As described below, thevarious interfaces presented to the user via the mobile wallet clientapplication 112 may include depictions of various user payment vehiclesand payment-related services. Accordingly, the mobile wallet circuit 154may identify user payment vehicles to include on the various interfaces.In some arrangements, the mobile wallet circuit 154 determines thevehicles to include based on information received from the user (e.g.,via the registration interfaces presented at 304). In some arrangements,the mobile wallet circuit 154 is configured to retrieve all useraccounts maintained at the financial institution accounts database 134and present all those accounts to the user regardless of whether theuser indicated a preference to provision them to the mobile wallet ornot.

In some arrangements, in the case of a new mobile wallet user, themobile wallet circuit 154 is configured to act in concert with thecustom credit authorization circuit 138 discussed above in relation tothe financial institution computing system 130 to incorporate adepiction of a new credit card account in the user's mobile wallet. Forexample, the custom credit authorization circuit 138 may transmit theterms of the new user's newly activated digital credit card account tothe mobile wallet circuit 154.

Having identified the user accounts, the mobile wallet circuit 154 maygenerate a graphical depictions of the user accounts (e.g., viaaccessing a content database) to present to the user via various mobilewallet interfaces to be described below. For example, the mobile walletcircuit 154 may retrieve carious card templates from a content databaseand incorporate user information (e.g., user name, account identifyinginformation, and the like) into such templates to produce depictions ofuser payment vehicles. Additionally, the mobile wallet circuit 154 mayalso generate a graphical depiction of a new user's newly activateddigital credit account created by via the processes discussed above.

In various embodiments, the mobile wallet circuit 154 may also identifya set functionalities to provide the user access to via the user'smobile wallet interfaces. For example, a user may be given access to aparticular functionality by way of a graphical depiction of thefunctionality on the user's mobile wallet interface that enables theuser to interface with program logic associated with the functionality.Accordingly, the mobile wallet circuit 154 may identify a set ofgraphical depictions to include in the user's mobile wallet interfaces.For example, the graphical interface may include graphicalrepresentations of various payment-related services to incorporate intothe user's mobile wallet interfaces based on the set of servicesidentified at process 314. In addition to the payment-related services,other depictions of other functionalities may be included. The otherfunctionalities may include, for example, the ability to use aparticular payment vehicle in a mobile wallet transaction, generalaccount management functions (e.g., balance-viewing, setting accountpreferences, and the like), and other payment-related services. Inanother example, in the case of a new mobile wallet user, the mobilewallet circuit 154 may include an account activation functionality inthe user's mobile wallet interfaces. The activation functionality mayenable the user to indicate a preference to activate a digital creditcard account from within the user's mobile wallet before receiving aphysical credit card in the mail.

In some arrangements, for each payment vehicle to be presented to theuser via the user's mobile wallet, the mobile wallet circuit 154 maygenerate a set of payment-related services and other functionalities topresent to the user. Each payment vehicle then, may have an associatedset of mobile wallet interface parameters indicating the positioning ofvarious graphical depictions of various functionalities incorporatedinto the interface.

At process 318, user payment tokens are generated. In variousarrangements, the mobile wallet circuit 154 performs a sequence togenerate one or more tokens for payment vehicles to be provisioned tothe user's mobile wallet and for the user's mobile device 110. Forexample, the mobile wallet circuit 154 may transmit user accountinformation and user mobile device information to the token serviceprovider computing system 140, which may generate the necessary tokens,store token-mapping information, and transmit the generated tokens tothe mobile wallet computing system 150 over the network 170.

At process 320, the user's mobile wallet information is stored. Forexample, information identifying various user payment vehicles, userinterface parameters, identified sets of services for the user, userauthentication credentials, and the like may be stored in the mobilewallet database 152 in association with a user's account.

Referring now to FIG. 4A, an exemplary registration interface 400 isshown according to an example embodiment. The interface 400 may bepresented to the user during the process 300 discussed above (e.g., atprocess 304). The interface may be presented on the user mobile device110 while the user mobile device 110 is implementing a web browser. Asshown, the interface 400 requests information from the user. Theinterface 400 includes a name dialogue box 402, an address dialogue box404, and a continue button 406. The continue button 406 causes the usermobile device 110 to transmit the entered information over the network170 to the mobile wallet computing system 150. The mobile walletcomputing system 150 may authenticate the user based on the user-inputinformation. For example, the mobile wallet circuit 154 may receive theuser input information, identify financial accounts (e.g., in thefinancial institution accounts database 134) associated with the user,and compare the user-input information with information stored in theaccounts database 134 to authenticate the user. It should be understoodthat, in some arrangements, different information may be requested fromthe user by the interface 400. For example, in one embodiment, theinterface 400 requests the user to input login credentials for a mobilebanking website provided by the financial institution computing system130.

In some arrangements, the initial registration interface presented tothe user during the registration process for a mobile wallet may bedifferent from the interface 400 discussed above. For example,initially, the user may be asked to indicate a preference to sign up fora new payment account (e.g., a credit card) with an associated financialinstitution (e.g., the financial institution associated with thefinancial institution computing system 130). In response to receivingsuch a preference, the mobile wallet circuit 154 may then present theuser with a prompt instructing the user to provide images of requireddocumentation (e.g., a driver's license, social security card, passport,other identification card, etc.). In response to the user taking animage of the documentation and transmitting the image to the mobilewallet circuit 154, the mobile wallet circuit 154 may in turn transmitthe image to the financial institution computing system 130 for analysisby the identity verification circuit 139. Further registrationinterfaces for user authentication may also be presented to the user forverification purposes. For example, the mobile wallet circuit 154 mayreceive a query specifically generated for the new mobile wallet user bythe identity verification circuit 139. The query may request the newuser to input personal information (e.g., in the form of a securityquestion). In this regard, the mobile wallet circuit 154 may receive theuser's response, and route the response to the identity verificationcircuit 139. Alternatively, the identity verification circuit 139transmits all verified user information (e.g., gained via a creditreport or other external information service) to the mobile walletcircuit 154 for comparing the user's responses to the verifiedinformation. In yet still other arrangements, responsive to the new userindicating a preference to register for a new payment account, themobile wallet circuit 154 may transmit a notification to the identityverification circuit 139, which may transmit the above mentionedregistration interfaces to the new user.

Referring to FIG. 4B, another registration interface 408 is shownaccording to an example embodiment. In some arrangements, the interface408 is presented to the user after the mobile wallet computing system150 identifies a financial account associated with the user andauthenticates the user based on the information input by the user intothe interface 400 discussed above in relation to FIG. 4A. As shown, theinterface 408 includes an account identifier window 410, anaccount-entering window 412, a cancel button 418, and a continue button420. The account identifier window 410 indicates user accounts that themobile wallet circuit 154 has identified based on information receivedfrom the user (e.g., information input by the user into the interface400 discussed above). The account identifier window 410 may present theuser with various accounts held by the user at the financial institutionassociated with the financial institution computing system 130. Theaccount-entering window 412 enables the user to input accounts otherthan those listed in the account identifier window 410. Accordingly, theaccount-entering window 412 provides a manual-entry button 416 thatenables the user to manually input account information and aphoto-capture button 414 enabling the user to activate a camera on themobile device 110 to take a photo of a payment vehicle to obtain paymentvehicle information (e.g., a PAN). In some arrangements, once the userenters information pertaining to a payment vehicle (e.g., via an imageor manual entry) and the user is authenticated (e.g., the mobile walletcomputing system 150 may identify the financial institutions associatedwith any account information entered by the user and transmit anauthentication request to the identified financial institution), theaccount identifier window 410 updates to include the newly-enteredaccount information.

In some arrangements, the user may select a payment vehicle in theaccount identifier window 410 and be presented with a tokenizationprompt instructing the user to indicate a preference to tokenize theselected payment vehicle. If the user indicates a preference to nottokenize the selected payment vehicle, the mobile wallet computingsystem 150 does not generate a token for the selected payment vehicle,but still incorporates the information pertaining to the payment vehicle(e.g., account number) into the user's mobile wallet to provide the userwith access to various functionalities described herein.

In the case of a new mobile wallet user, alternative account-relatedinterfaces may be presented to the new user. For example, the user maybe presented with a pre-populated account application form includingvarious fields. The fields may request information from the user (e.g.,identity information, an address, employment history, sources of income,references, etc.). In various arrangements, at least a portion of thefields are pre-populated with verified user information. For example,the identity verification circuit 139 may transmit verified userinformation to the mobile wallet computing system 150. In turn, themobile wallet circuit 154 may use this information to pre-populate asubset of fields in a credit card application template. In variousarrangements, all or nearly all of the fields in the credit applicationare pre-populated with the verified user information. For example, inone embodiment, all that a new user needs to input into the credit cardapplication is any sources of income or expenses that are not identifiedby the pre-populated form. In another embodiment, the user may also haveto input identification information (e.g., a social security number)into the application. Any information input by the user may betransmitted to the identity verification circuit 139 and/or customcredit approval circuit 138 to be used to verify the user and in aprocess for creation of a new user credit account.

Referring now to FIG. 4C, another registration interface 422 is shownaccording to an example embodiment. In some arrangements, the interface422 is presented to the user responsive to the user pressing thecontinue button 420 of the interface 408 discussed above. As shown, theinterface 422 enables the user to establish a PIN that is used toauthenticate a mobile wallet user and includes a pin-entry dialogue box424, a cancel button 426, a save button 428 for saving a user PINentered via user-entry graphic 430.

Referring now to FIG. 4D, another registration interface 432 is shownaccording to an example embodiment. In some arrangements, the interface432 is presented to the user responsive to the user establishing a PINvia the registration interface 422 discussed above. As shown, theinterface 432 includes an service-listing window 434, a cancel button436, and a registration button 438. The service-listing window 434presents the user with a list of payment-related service descriptions.For example, responsive to a user selection of the service-listingwindow 434, the user may be presented with a series of payment relatedservice descriptions, and the user may select any number of the showndescriptions to indicate a preference as to which services that the useris interested in. In various arrangements, the preferences indicated bythe user are used by the mobile wallet circuit 154 in the selection ofpayment-related services to present to the user in various mobile-walletinterfaces. The cancel button 426 enables the user to cancel theregistration process. The registration button 438 causes the preferencesinput by the user to be transmitted to the mobile wallet computingsystem 150, which may perform various steps (e.g., processes 310-316 ofthe method 300 discussed above) to complete the user's registration foruse of the mobile wallet.

In various arrangements, in situations where the new mobile wallet useris signing up for a new payment account at the financial institution,for example, further registration interfaces may be presented to theuser. For example, if a particular new mobile wallet user is approvedfor a new credit card by the financial institution, and a digital creditcard account has already been created for the user, another registrationinterface may enable the user to indicate a preference to activate thenew account such that, upon the user's first activation of the mobilewallet client application 112 on the user mobile device 110, the digitalcredit card account is available for use in the user's mobile wallet. Inresponse to the user indicating such an activation preference, anotification may be relayed to the financial institution computingsystem 130 so that activation procedures described below are performedto make the digital credit card account available for use.

Turning now to FIG. 5A, an example mobile wallet interface 500 displayedby the user mobile device 110 is shown. In various arrangements, theinterface 500 may be presented by the mobile wallet client application112. As shown, the interface 500 includes a first field 502, a secondfield 516, and a third field 526. The first field 502 and the secondfield 516 are payment-vehicle-centric (e.g., the fields update dependingon a payment vehicle that is selected by the user), while the thirdfield is user-centric (e.g., the third field remains the sameirrespective of the payment vehicle that the user has selected). Itshould be understood that in various other embodiments, the interface500 may include more, less, or different fields. For example, in oneembodiment, the interface 500 may only include the first field 502 andthe second field 516, and the first field 502 or the second field 516may include an option that brings the user to another interface thatincludes the elements of the third field 526 described below. In anotherexample, the interface 500 includes a fourth field that indicates astatus (e.g., whether the payment vehicle is provisioned to the mobilewallet) of a payment vehicle depicted in the first field 502 and enablesthe user to perform a transaction at a merchant using the paymentvehicle or provision the payment vehicle to the user's mobile wallet.

The first field 502 enables the user to select from various paymentvehicles and view information pertaining to the selected paymentvehicles. As shown, it includes a first payment vehicle depiction 504,first card identifying information 506, a card selection indicator 508,a second payment vehicle depiction 510, a balance-viewing button 512,and a payment button 514. It should be understood that, as used herein,the term “depiction” is meant be interpreted broadly. Any graphicalrepresentation of any item, functionality, or entity including any sortof information to identify what is depicted is within the scope of“depiction” as used herein. The first payment vehicle 504 is a graphicaldepiction of a first payment vehicle that the user has provisioned tothe mobile wallet. In various arrangements, the first payment vehicledepiction 504 may include a selected payment vehicle that the user haschosen/designated for mobile wallet transactions. The first-cardidentifying information 506 includes portions of various identifiersassociated with the first payment vehicle (e.g., portions of a token orPAN associated with the payment vehicle).

In various embodiments, the user can alter the payment vehicle thattakes the position of the first payment vehicle 504 in the interface 500by interacting with the interface 500 in various ways. As shown, theinterface 500 includes a card selection indicator 508 and a secondpayment vehicle depiction 510. In some arrangements, the card selectionindicator 508 indicates two things: the numbers of payment vehicles thatthe user has that are eligible for use in the mobile wallet and theposition of the currently selected payment vehicle (e.g., the firstpayment vehicle as shown). The user updates the first field 502 byinteracting with the first field. For example, in some arrangements, theuser interacts with the first payment vehicle depiction 504 to removethe first payment vehicle depiction 504 from its current position andreplace the first payment vehicle depiction 504 with the second paymentvehicle depiction 510. The user may touch the a screen included in theuser I/O device 118 corresponding to the first payment vehicle depiction504 and swipe the screen in a direction (e.g., to the left, to theright, upwards, or downwards) so as to place the second payment vehicledepiction 510 in the position of the first payment vehicle depiction 504as shown in the interface 500. In various arrangements, once the secondpayment vehicle depiction 510 is in the position of the first paymentvehicle depiction 504, it is “selected” by the user for use in themobile wallet (e.g., the user can hit the payment button 514 to initiatea mobile wallet transaction using the second payment vehicle). Invarious arrangements, the user can select from amongst a plurality ofdifferent payment vehicles. In some arrangements, the user may selecteach payment vehicle that has provisioned to the user's mobile wallet(e.g., through the registration interface 408 discussed above inrelation to FIG. 4C). In other arrangements, even cards that have notbeen provisioned to a user mobile wallet are selectable via the firstfield 502.

As shown herein the various payment vehicles viewable via the firstfield 502 are horizontally disposed in relation one another such thatthe “selected” payment vehicle translates to the right or left upon theuser interacting with the first field 502. In alternative arrangements,the various payment vehicles may be disposed on the interface in variousdirectional relations to one another. For example, the payment vehiclesmay be vertically disposed in relation to one another, and the userwould have to swipe up and down to select a new payment vehicle. Inanother example, all the payment vehicles may be simultaneously viewablein the first field 502, and the first field may include a selectionportion. The various depictions of the various payment vehicles may be“dragged” by the user on the mobile wallet interface (e.g., the userpresses a payment vehicle depiction with a finger, and moves the paymentvehicle depiction to another position). To “select” a particular paymentvehicle, the user may “drag” the selected payment vehicle to theselection portion included in the first field 502.

Balance-viewing button 512 enables the user to view balance informationassociated with the payment vehicle in the position of the first paymentvehicle depiction 504. In various arrangements, responsive to the userselecting the balance-viewing button, the second field 516 may beupdated to include a balance-viewing overlay whereby the user ispresented with account balance information pertaining to the firstpayment vehicle depiction 504. For example, upon the user's selection ofthe balance-viewing button 512, the user mobile device 110 may transmita balance-request to the financial institution computing system 130,which may in turn retrieve the user's balance from the accounts database134 and transmit the balance to the user mobile device 110. Upon receiptby the user mobile device 110, the information may be viewable by theuser as an overlay of the second field 516, an alternative mobile walletinterface, or as an overlay to the first field 502.

The payment button 514 enables the user to make a payment with thepayment vehicle in the position of the first payment vehicle depiction504. For example, responsive to the user selecting the payment button514, the mobile wallet client application 112 may configure the usermobile device 110 to initiate wireless communications with a merchantpoint of sale device (e.g., NFC communication) to transfer a token tothe point of sale device and initiate the user making a payment using apayment vehicle depicted by the first payment vehicle depiction.

The second field 516 of the interface 500 enables the user to takevarious actions with respect to the payment vehicles viewable in thefirst field 502. As shown, the second field includes a first paymentservice depiction 518, a second payment service depiction 520, a historybutton 522, and an account-management button 524. The payment servicedepictions 518 and 520 provide access to payment-related servicesoffered by the mobile wallet provider, financial institution, or thirdparties by enabling the user to activate and provide input to thesoftware integration packages discussed above. In some arrangements, thesecond payment service depiction 520 may be associated with a deeplinking functionality that is configured to launch a third party clientapplication 116 associated with the depicted service on the user mobiledevice 110.

In some arrangements, the graphical depictions of the payment relatedservices are associated with various integration packages thatincorporate various functionalities into the mobile wallet clientapplication 112. For example, in response to selection of such adepiction, the user may be brought to a further interface enabling theuser to take advantage of a subset of functionalities accessible to theuser via a separate third party client application 116 without everleaving the mobile wallet client application. For example, the mobilewallet client application 112 may include a driving service widget andthe second service depiction 520 may include a depiction of the drivingservice (e.g., Uber® or Lyft®). By selecting a payment vehicle in thefirst field 502 and interacting with the second payment servicedepiction 520, the user may cause the user mobile device 110 tocommunicate a ride request to the third party computing system 160associated with the driving service (e.g., to be picked up at the user'scurrent location and pay using the selected payment vehicle). Further,in this same example, the first payment service depiction 518 mayinclude a link to a mobile shopping application. By selecting a paymentvehicle in the first field 502 and selecting the first payment servicedepiction 518, the user may be brought to a further interface enablingthe user to make a purchase with the selected payment vehicle. Thus, inthis example, by simply selecting a payment vehicle, the user has accessto a plurality of different ways to use the payment card that areaccessible through a single tap on the mobile wallet interface.

The payment-related services depicted in the second field 516 may bear arelationship to the payment vehicle depicted by the first paymentvehicle depiction 504. As discussed above, during the registrationprocess for the mobile wallet, a set of payment-related services isselected for the user. This set of services may include more servicesthan those are depicted in the second field 516 of the mobile walletinterface. Accordingly, the mobile wallet circuit 154 (e.g., via theuser interface management circuit 220) or mobile wallet clientapplication 112 may select a subset of the selected services to includein the second field 516 based on the selected payment vehicle. In somearrangements, the subset is selected based on characteristics of theselected payment vehicle. In the example shown, the selected paymentvehicle is a user debit card. Accordingly, responsive to the user'sselection of the debit card, the mobile wallet circuit 154 may select aset of services that are compatible with the debit card. To illustrate,the first payment service depiction 518 may include a link to a billpayment application offered by a financial institution that enables theuser to pay bills using the selected debit card. The second servicedepiction 520 may depict a P2P payment widget that brings the user toanother interface enabling the user to select a recipient and transferfunds to the selected recipient using the debit card.

Still referring to this example, if the user were to further manipulatethe first field 502 so as to select an alternative payment vehicle suchas a credit card, the service depictions 518 and 520 may update torepresent different functionalities that are compatible with the creditcard. Instead of depicting a bill payment application, the first paymentservice depiction 518 may represent a credit card rewards widget thatenables the user to view the rewards that the user has earned throughusage of the selected credit card. The second service depiction 520 maybe updated to represent a mobile shopping application associated with amerchant that enables the user to earn an enhanced amount of financialrewards associated with the selected credit card (e.g., the user mayearn 2% cash back at the designated merchant but only 1% cash back forall other transactions). Thus, the depictions 518 and 520 dynamicallyupdate to provide the user with access to a set functionalities that areoptimized given the user's payment vehicle selection.

In various arrangements, the services presented to the user on theinterface 500 may update based on user preferences. For example, byhitting the settings button 538, the user may be brought to a serviceselection window similar to the service-listing window 434 discussedabove in relation to FIG. 4D. The service selection window enables theuser to select which services that the first service depiction 518 andsecond service depiction 520 (and any additional service depictionsincluded in the second field 516) represent. For example, responsive toa user selection of the service in the service selection window, userinterface parameters associated with the user mobile wallet to beupdated such that the selected services are viewable when the associatedpayment vehicle is selected by the user. For example, if the selectedservice is already included in the mobile wallet client application 112(e.g., the integration package associated with the selected service wastransmitted to the user mobile device 110 during the process 3000discussed above), the processor of the user mobile device 110 may updatethe user's interface parameters so as to expose the selected service. Ifthe selected service is not included in the user mobile wallet clientapplication 112, the user mobile device 110 may communicate the user'spreference to the mobile wallet circuit 154, which may update the mobilewallet client application 112 to incorporate the user-identifiedservice, and update the mobile wallet client application 112 to includethe graphics and program logic associated with the selected service inthe user's mobile wallet.

Alternatively or additionally, the services presented to the user on theinterface 500 may update automatically based on the user's interactionswith the interface 500. For example, the mobile wallet clientapplication 112 may keep track of the user's interactions with theservice depictions 518 and 520 to create historical usage data. Themobile wallet client application 112 (e.g., via either program logicstored in a system memory of the user mobile device 110 or in the mobilewallet circuit 154) may determine the user's usage rate of the depictedservice and update the services depicted in association with theselected payment vehicle if the usage rate drops below a predeterminedthreshold. For example, the mobile wallet client application 112 maydetermine a probability of a user utilizing a depicted service each timethe user activates the mobile wallet client application 112 based on thehistorical usage data. When the probability drops below a predeterminedthreshold, the user interface parameters associated with the user'smobile wallet may be updated to include the depiction of an alternativepayment-related service. Each time the user's interfaces are updated toshow a different payment-related service, the mobile wallet clientapplication 112 may notify the user. The notification may include adescription of the newly inserted service, and enable the user to set upan account with any third party if necessary.

Alternatively or additionally, the services and/or payment vehiclespresented to the user on the interface 500 may dynamically update basedon the user's location. For example, the mobile wallet clientapplication 112 may receive user location data form a GPS locatorassociated with the user mobile device. The user's current location maybe compared with baseline location information describing the locationof various merchants and the like. If the processor of the user mobiledevice 110 or mobile wallet circuit 154 determines that the user iswithin a predetermined distance of a baseline location, for example,relationships between the baseline location and user payment vehicles orpayment-related services may be determined. For example, if the user isclose to a merchant, the processor of the mobile device or the mobilewallet circuit 154 may determine if the user has a gift card at themerchant, a mobile shopping widget associated with the merchant, or arewards program associated with the merchant. If so, the first field 502and the second field 516 may update to include the payment vehiclesand/or payment related services related to the merchant.

Still referring to FIG. 5A, in addition to including payment servicedepictions 518 and 520, the second field 516 further includes depictionsof more general banking services 522 and 524. As shown, the second field516 includes a history button 522 enabling the user to view atransaction history of the selected payment vehicle and an accountmanagement button 524. The management button 524 enables the user tomanage an account associated with the payment vehicle depicted by thefirst payment vehicle depiction. For example, in some embodiments, themobile wallet client application 112 may enable the user to interfacewith an account management circuit 136 of the financial institutioncomputing system 130. Upon selection of the management button, the usermay be brought to an interface that enables the user to set variousparameters for the account (e.g., security settings and the like). Insome arrangements, upon hitting the management button 524, the user maybe able to indicate a preference to activate or deactivate the selectedpayment vehicle. If the user indicates such a preference, the usermobile device 110 may store and transmit a deactivation preference tothe financial institution computing system 130 and/or mobile walletcomputing system. In response, the financial institution computingsystem 130 may place a hold on the account associated with the selectedpayment vehicle preventing the payment vehicle from being used in anykind of transactions. Additionally, the mobile wallet computing system150 may take steps to de-tokenize the selected payment vehicle. Forexample, the mobile wallet computing system 150 may transmit adeactivation notification to the token service provider computing system140 that causes the token service provider computing system 140 todeactivate (e.g., delete or otherwise render inoperable) a token storedin association with the selected payment vehicle from the token vault.In some arrangements, the token may not be deleted by the token serviceprovider computing system 140 and/or mobile wallet computing system 150,but rather temporarily deactivated or rendered inoperable. For example,an inactivation identifier may be stored in association with the tokenin the token vault to prevent the token from being transmitted to, forexample, the user mobile device 110 to prevent the user from completinga mobile wallet transaction with the deactivated account. Once a paymentvehicle has been deactivated, the user mobile device 110 may transmit auser activation preference responsive to receiving a user preference toreactivate the selected payment vehicle and aforementioned steps may bereversed to enable the user to perform mobile wallet transactions usingthe selected payment vehicle.

The third field 526 provides the user with a series of user-centricfunctions in the mobile wallet. As shown, the third field 526 includesin interface-selection button 528, a loyalty button 530, a rewardsbutton 532, an offers button 534, a sign off button 536, a settingsbutton 538, a manage wallet button 540, and a help button 542. In someembodiments, the interface selection button 528 enables the user toselect a nature of the first and second fields 502 and 516 viewable bythe user. For example, in one embodiment, responsive to user selectionof the interface selection button 528, the user is presented with a listof interface options. In various embodiments, the options enable theuser to select the centrality of the first field 502 and the secondfield 516. As shown in FIG. 5A, the first and second fields 502 and 516present the user with a payment vehicle-centric view (e.g., the panels'appearance depends on the payment vehicle selected by the user). Invarious arrangements, the interface options enable the user to selectbetween a card-centric view, a payment network-centric view, and apayment service-centric view. For example, if the user selected thepayment network-centric view, instead of being able to toggle betweenpayment vehicles by interacting with the first field 502, the user isable to toggle between various payment networks/rails (e.g., Visa®,Mastercard®, and the like) in the first field 502. Various user paymentcards associated with the selected payment network may be viewable bythe user to be used in the mobile wallet. Upon user selection of apayment card, a second field similar to the second field 516 shown inFIG. 5A may be presented to the user. If the user selects a paymentservice-centric view, the user may be able to toggle between variouspayment-related services (e.g., mobile wallets, P2P payment services,and online shopping applications) via the first field 502. Via selectionof a particular payment service via the first field 502, the secondpanel 516 may present the user with a second panel including variousfunctionalities (e.g., a history button 522 or manage button 524)allowing the user to set preferences pertaining to the selected service.

The loyalty button 530 enables the user to access various loyaltyprograms (e.g., loyalty cards or programs associated with particularmerchants. The rewards button 532 presents the user with rewards thatthe user has earned through utilization of the mobile wallet. Forexample, the user may earn various rewards (e.g., points, cash back, andthe like) through conducting various transactions using the paymentvehicles that have been provisioned to the mobile wallet. In somearrangements, responsive to user selection of the rewards button 532,the user is presented with an interface that enables the user toallocate any earned rewards towards an upcoming mobile wallettransaction.

The sign off button 536 enables the user to exit the mobile walletclient application 112. The settings button 538 enables the user to setvarious parameters for the mobile wallet (e.g., default interface views,communication settings, and the like). The wallet management button 540enables the user to perform various operations with respect to the userwallet. Operations may include, for example, the provisioning of newpayment vehicles to the mobile wallet, removal of payment vehicles fromthe mobile wallet, authentication information (e.g., a PIN), and thelike. The help button 542 allows the user to access an interface thatinstructs the user on how to perform the various operations describedherein.

Turning now to FIG. 5B, an updated user mobile wallet interface 544 isshown according to an example embodiment. As shown, the interface 544 issimilar to and shares many of the same aspects as the interface 500discussed above in relation to FIG. 5A, but has several differences. Insome arrangements an interface such as the interface 544 is presented tothe after the user manipulates the first field 502 of the interface 500to select the second payment vehicle depiction 510 shown therein. Asshown, the second payment vehicle depiction 510 now occupies theposition formerly occupied by the first payment vehicle position 504,and the first payment vehicle depiction 504 is displaced from itsoriginal position. The selection indicator 508 has been updated toreflect the user's selection of the second payment vehicle depiction510. Additionally, the first field 502 includes a third payment vehicledepiction 548.

In the example shown in FIGS. 5A-5B, the second payment vehicle depictedby the second payment vehicle depiction 510 is a credit card. As shown,the second field 516 of the interface 544 contrasts with the secondfield 516 of the interface 500 because, in the interface 500, theselected payment vehicle was a debit card. The second field 516 includesa depiction 550 of a third payment-related service instead of thedepiction 520 of the second payment-related service. Such an update maybe due to the different qualities of the selected payment vehicles. Forexample, the depiction 520 of the second payment-related service mayhave been a depiction of a P2P payment service (e.g., Zelle™) that isnot compatible with credit cards. Accordingly, responsive to the userselection of the second payment vehicle, the depiction 520 is replacedwith the third depiction 550 that depicts a credit-compatible service(e.g., an online shopping payment service such as Visa Checkout®). Thus,the second field 516 is dynamically updated so that the user ispresented with payment-related services that are compatible with theselected payment vehicle. As will be appreciated, in variousarrangements, the number of payment-related services depicted in thesecond field 516 may vary. For example, a particular user may have twopayment vehicles selectable via manipulation of the first field: acredit card and a gift card. The credit card may have an associatedsecond field 516 that includes three payment-related service depictions,such as a rewards widget enabling the user to manage financial rewardsassociated with the credit card, and links to two mobile shoppingapplications. The gift card, however, may only include a singlepayment-related service depiction such as a shopping applicationassociated with the merchant at which the gift card is usable.

In some arrangements, the payment vehicles that are viewable andselectable by the user via manipulation of the first field 502 arecontrollable by the user. For example, in some arrangements, onlypayment vehicles that have been added to the user's mobile wallet areviewable in the first field 502. Thus, in order for a particular userpayment vehicle to be viewable in the first field, the user would firsthave to provision the card to the mobile wallet via a wallet managementscreen (e.g., presented when the user selects the wallet managementbutton 540 discussed above). In alternative arrangements, any userpayment vehicles that have been identified as being associated with theuser are viewable and selectable by the user via the first field 502.For example, if the mobile wallet computing system 150 communicates withthe financial institution computing system 130 to identify various useraccounts, each user account may be viewable and selectable via the firstfield 502 irrespective of whether the user has indicated a preference toprovision the payment vehicle to a mobile wallet.

In this regard, FIG. 5C shows an updated mobile wallet interface whereinthe third payment vehicle depiction 548 is associated with a paymentvehicle (a credit card) that has not yet been provisioned to the user'smobile wallet. As shown, the interface 552 includes a third paymentvehicle depiction 548, a fourth payment vehicle depiction 554, and aprovisioning button 556. The provisioning button 556 replaces thepayment button 514 included in the interfaces 400 and 544 discussedabove because the third payment vehicle has not yet been added to theuser's mobile wallet. In some arrangements, the provisioning button 556initiates a tokenization process discussed above to allow the user touse the credit card for mobile wallet transactions.

This last example illustrates another benefit of the multi-functionmobile wallet described herein. Because functionalities other thantraditional mobile wallet features (e.g., engaging in POS transactionsusing the mobile device 110) are provided, the payment vehicles need notbe tokenized or added to a user's mobile wallet for their inclusion tobe useful. For example, the user can still take advantage of variouspayment-related services provided in the second field 516 usingnon-provisioned payment vehicles. Thus, the systems and methodsdisclosed herein provide for a more effective organization of userpayment vehicles than current systems. The user need not access aseparate application or a wholly different interface to be able toperform various actions with respect to both provisioned andnon-provisioned payment vehicles. To illustrate, a user may conduct aPOS transaction using a first provisioned payment vehicle, and view anaccount balance on a non-provisioned payment vehicle by doing nothingmore than performing a swiping action in the first field 502. Such quickand efficient access to such a variety of functionalities is animprovement over existing systems.

Further in this regard, payment vehicles need not even be currentlyactivated for their inclusion to be useful in the multi-function mobilewallet. In situations where a user temporarily deactivates a paymentvehicle, such a feature is especially useful. For example, a user may,via a mobile banking application or the mobile wallet client application112, provide an input to the financial institution computing system 132to deactivate a payment vehicle. In response, the financial institutioncomputing system 130 may transmit a notification to the token serviceprovider computing system 140, which may in turn delete or otherwiserender inoperable any tokens associated with the payment vehicle. Suchloss of a token may cause the user payment vehicle to be removed fromthe user's mobile wallet in current systems. In such current systems, tomake the card viewable in the user's mobile wallet once again, the userwould have to re-provision the card to the mobile wallet (e.g., throughan interface similar to the registration interface 408 discussed abovein relation to FIG. 4B) once the card is reactivated. This is atime-consuming, burdensome, and irritating user experience. By notrequiring tokenization to be viewable in the first field 502, themulti-function mobile wallet disclosed herein enables users to takevarious actions with respect to a payment vehicle even if the paymentvehicle is deactivated.

In this regard, FIG. 5D shows a mobile wallet interface 558 thatincludes an inactivated payment vehicle according to an exampleembodiment. As shown, the interface 558 includes a fourth paymentvehicle depiction 554 and a deactivation indication 560. As shown inFIG. 5D, the fourth payment vehicle depiction 554 has a differentcharacteristic than any of the first, second, or third payment vehicledepictions, 504, 510, and 548 (as indicated by the dashed line) due toits different activation. In some arrangements, the differentcharacteristic takes the form of a color characteristic. For example,active payment vehicles (e.g., first, second, or third payment vehicledepictions, 504, 510, and 548) may be presented to the user in colorform, while inactive payment vehicles (e.g., the fourth payment vehicledepiction 554) may be presented in a black and white or grayscale form.Alternative differentiation schemes are envisioned. For example, thefirst field 502 may be divided into various subdivisions for eachclassification of payment vehicle (e.g., (a) active, provisioned tomobile wallet, and default mobile wallet card; (b) active andprovisioned to mobile wallet; (c) active and not provisioned to mobilewallet; and (d) inactive) displayed therein. The subdivisions may beviewable simultaneously in the first field 502, and the user mayinteract with one subdivision independently of any of the othersubdivisions. For example, the user may toggle between the various cardswithin each subdivision, and press on a particular payment vehicle toselect a payment vehicle. Any mode of contrast between active andinactive payment vehicles may be used in accordance with the embodimentsdescribed herein.

As shown in FIG. 5D, the second field 516 is also updated to reflect theselected payment vehicle being deactivated. In this embodiment, thesecond field 516 does not include any depictions of any otherpayment-related services, but still provides the user with access toaccount history via the history button 522. This prevents the user fromattempting to engage in transactions using a deactivated paymentvehicle, but still enables the user to perform certain functions withrespect to deactivated payment vehicles. Further, the second field alsoincludes a management button 524. In various arrangements, the user mayhit the management button, and indicate a preference to both re-activatea payment vehicle and re-add the payment card to the mobile wallet. Insome arrangements, such a re-activation feature is included in the firstfield 502 or the second field 516. In any event, the re-activationfeature is configured to provide an input to the program logic beingexecuted by the user mobile device 110 to transmit a re-activationpreference to the financial institution computing system 130. In turn,the financial institution computing system 130 may re-tokenize thedeactivated payment vehicle via any of the methods disclosed herein andtransmit a notification to the user mobile device 110. In response tothis notification, the mobile wallet interface presented to the user maybe updated to include an updated depiction of the deactivated paymentvehicle as well as a payment button. That way, the user can immediatelyreactivate a deactivated payment vehicle. In response the interface 558may update to resemble the interface 500 discussed above, and enable theuser to use the fourth payment vehicle in various transactions.

It should be noted that any of the mobile wallet interfaces disclosedherein may include a deactivation icon as well. The deactivation iconmay be included in the first field 502 or the second field 516 and beconfigured to provide an input to the program logic being executed bythe user mobile device 110 causing the user mobile device 110 totransmit a deactivation preference to the financial institutioncomputing system 130. Further in response to receiving the userdeactivation preference, the processor of the user mobile device 110 mayupdate the user's mobile wallet interface to present the deactivatedpayment vehicle via any of the means discussed above. Thus, the mobilewallet interfaces disclosed herein update not only response to userselection of payment vehicles, but also user activation preferences asto various payment vehicles.

It is useful here to note that, in various arrangements, the mobilewallet client application 112 may cause a processor of the user mobiledevice 110 to undergo an initiation process each time the mobile walletclient application 112 is activated by the user. Such an initiationprocess may occur each time, for example, the user presses on a mobilewallet icon included on a main system screen of the user mobile device110. Included in this initiation process, among other things, is asystem sweep for user payment vehicles. For example, program logicincluded in the mobile wallet client application 112 may cause theprocessor to retrieve payment vehicle information from a system memoryor storage on the user mobile 110. The retrieved information mayinclude, for example, account numbers (or portions thereof), tokens, theassociated financial institution, an activation status of the paymentvehicle, account balance information and the like. Such information maybe stored in the user mobile device 110 upon completion of theregistration process 300 discussed above. Alternatively or additionally,the processor may transmit an information request to the mobile walletcomputing system 150, financial institution computing system 130, and/ortoken service provider computing system 140 to request all or a portionof this information. Using this information, the processor configuresthe user's mobile wallet interfaces. Unlike current systems, paymentvehicles not including a token or that are deactivated are stillpopulated in the user's mobile wallet, but under a differentiationscheme. For example, un-tokenized payment vehicle interfaces may beconfigured to include a provisioning feature enabling the user tocommunicate a tokenization preference to the financial institutioncomputing system 130, while deactivated payment vehicles may include adeactivation notification and be colored differently than the activatedpayment vehicles.

To summarize what is illustrated in FIGS. 5A-5D, according to thesystems and methods disclosed herein, multiple classes of paymentvehicles may be viewable by the user in the first field of the mobilewallet interface. In some embodiments, only active payment vehicles thathave been provisioned to the mobile wallet through an account selectionscreen (e.g., similar to the interface 408 discussed above with respectto FIG. 4B) are viewable and selectable via the first field. In otherembodiments, all active payment vehicles that have been identified bythe mobile wallet computing system 150 as belonging to the user, eitherprovisioned to the mobile wallet or not, are viewable and selectable viathe first field. In yet still other embodiments, all historical paymentvehicles that have been identified by the mobile wallet computing system150 as belonging to the user, whether active or inactive, provisioned ornot provisioned, are viewable and selectable via the first field. Forexample, in some embodiments, in the case of a brand new mobile walletuser without any existing accounts, the first field of the mobile walletinterface may only include a depiction of a single payment vehicle: anewly activated digital credit card account. Initially, the newlyactivated account may be accompanied by an activation preference buttonor the like that enables the user to indicate a preference to activatethe account prior to the user receiving a physical credit card in themail. In response to the user activating the account, the interface mayupdate to include a payment functionality (e.g., the payment button 514)to enable the user to nearly immediately (e.g., less than 10 secondsfrom indicating an activation preference) use the digital credit accountto complete transactions.

Referring now to FIG. 6 , a payment functionality interface 600presented to the user via the user's mobile wallet is shown according toan example embodiment. In some arrangements, the user is brought to thepayment functionality interface 600 responsive to selecting a depictionof a payment-related service on a user-default mobile wallet interfacesuch as the interface 500 shown in FIG. 5A. The interface 600 shown inFIG. 6 depicts the specific example where the user first activates themobile wallet client application 112 on the user mobile device 110 andis brought to the interface 500 discussed above in relation to FIG. 5A.In the example, the user does not manipulate the first field 502 of theinterface 500 so as to select an alternative payment vehicle to the onedepicted by the first payment vehicle depiction 504. Instead, the userselects the depiction 518 of the first-payment related service, which isa person-to-person payment service provided by a third party computingsystem 160.

In some arrangements, the first depiction 518 of the first paymentservice may be a widget pre-configured by a third party or the mobilewallet provider. Responsive to user selection of the widget, the usermobile device 110 may be communicatively coupled to the third partycomputing system 160 at which the payment-related service is provided.As shown, the interface 600 includes an account selection window 602, apayment recipient window 604, a payment button 606, and options 610-618.The options 610-618 are similar to options 528-538 discussed above inrelation to FIG. 5A. In some arrangements, the mobile wallet clientapplication 112 is configured to pre-populate certain fields in thefunctionality interface 600 based on the state of the mobile walletinterface through which the functionality interface 600 was accessed.For example, as shown, the account selection window 602 is pre-populatedwith the debit card that was depicted by the first payment vehicledepiction 504 of the interface 500. Thus, because the user selected thedepiction 518 of the first payment-related service while a debit cardwas in the position of the first payment vehicle depiction 504, thefunctionality interface 600 pre-populates the relevant payment fieldwith that account. In some arrangements, the user may select the accountselection window 602 and be presented a list enabling the user to selectan account from which to transfer funds.

The payment recipient window 604 enables the user to select from a listof recipients the person to which to transfer funds. In somearrangements, the list presented to the user by the payment recipientwindow is populated based on a user account with the third party. Forexample, the user may already have an application (e.g., a third partyclient application 116) provided on the user mobile device 110 thatenables the user to utilize the P2P payment service. The mobile walletclient application 112 (e.g., the third party integration circuit 114)may include an API that facilitates the integration of the mobile walletclient application 112 with the third party client application 116. TheAPI may configure the mobile wallet client application 112 to retrieveuser information stored in association with the third party clientapplication 116. The payment button 606 enables the user preferencesindicated via the account selection window 602 and recipient window 604to be communicated to the third party computing system 160 over thenetwork 170. The third party computing system 160 may complete therequested transaction and communicate a notification to the user mobiledevice 110 that is viewable via the user's mobile wallet. Thus, the useris seamlessly provided with access to various functionalities providedat various computing systems associated with various entities withoutever having to leave the mobile wallet.

Referring now to FIG. 7 , a payment vehicle history interface 700 isshown according to an example embodiment. In various arrangements, theuser may be brought to a payment history interface such as the interface700 responsive to hitting the history button 522 on the interface 500discussed above in relation to FIG. 5A. As shown, the interface 700presents a transaction history to the user for a certain payment vehicle(e.g., the payment vehicle that was “selected” by the user when the userhit the history button 522). As such, the interface 700 includes atransaction history of the payment vehicle depicted by the first paymentvehicle depiction 504.

As shown, the transaction history includes a listing of transactions702, 704, 706 that the user has engaged in using the payment vehicledepicted by the first payment vehicle depiction 504. The interface 700also includes a receipt button 708, and a reporting button 710. Theinterface also includes options 712-720 that are similar to options528-536 discussed above in relation to FIG. 5A. As indicated by thedashed line, the user has selected the transaction 704. By selecting thetransaction 704, the user can view a receipt associated with thetransaction by pressing the receipt button 708 or report the transactionas fraudulent using the reporting button 710. Referring generally thesystems and methods herein, the mobile wallet client application 112 mayenable the user to receive and review receipts for various transactions.Such functionalities are discussed in greater detail in U.S. Ser. No.14/464,505, filed Aug. 20, 2014 entitled “Systems and Methods forReceipt Tracking in a Mobile Wallet,” hereby incorporated by referencein its entirety in this regard. Using the methods described therein, themobile wallet client application 112 may present the user with anotherinterface including a receipt from the selected transaction 704. Byselecting the reporting button 710, the user can initiate a sequence tocommunicate a fraudulent transaction to the financial institution withwhich the payment vehicle is associated. For example, responsive to theuser selecting the reporting button 710, a notification may becommunicated to the mobile wallet computing system 150, which mayidentify the financial institution computing system 130 associated withthe payment vehicle and communicate the fraudulent transaction to thefinancial institution computing system 130, which may in turn deactivatethe user account. Responsive to the deactivation, the mobile walletcomputing system 150 may update the user's mobile wallet interface suchthat the depiction of that payment vehicle indicates that the account isdeactivated (e.g., like the payment vehicle depiction 554 discussedabove in relation to FIG. 5D).

Referring now to FIG. 8 , an example mobile wallet loyalty interface 800is shown according to an example embodiment. In various arrangements,the user may be brought to the loyalty interface 800 responsive toselecting any of the loyalty buttons 530, 612, or 714 discussed above inrelation to the interfaces 500, 544, 552, 558, 600, and 700. As shown,the loyalty interface 800, like the interface 500 discussed above inrelation to FIG. 5A, includes a first field 802, a second field 814, anda third field 822. The third field 822 is similar to the third field 526of the interface 500 discussed above and includes options 824-832similar to options 528-536 discussed above. The first field 802 issimilar in appearance to the first field 502 discussed above, butincludes depictions of user loyalty accounts rather than depictions ofuser payment vehicles. As shown, the first field 802 includes a firstloyalty account depiction 804, an account selection indicator 806, aloyalty account number indicator 808, a second loyalty account depiction810, and a payment button 812. The first loyalty account depiction 804depicts a first loyalty account that the user has provisioned to themobile wallet. Loyalty accounts may be provisioned to the mobile walletin similar ways to payment vehicles (e.g., as described above inrelation to the registration interface 408 discussed above in relationto FIG. 4B). Once provisioned to the mobile wallet, the user caninitiate a process to transmit the loyalty account information to amerchant by pressing the payment button 812. Similar to the first field502 discussed above, the user can manipulate the first field 802 so asto select another loyalty account (e.g., the second loyalty accountdepiction 510).

The second field 814 enables the user to perform various operations withrespect to the loyalty account. The management button 816, historybutton 818, and addition button 820 may perform similar functionalitiesas discussed above in relation to general user payment vehicles. Forexample, by pressing the management button 816, the user may associatepayment vehicles (e.g., payment vehicles that the user has provisionedto the mobile wallet) with a loyalty account such that, when the userindicates a preference to transmit the loyalty account information to amerchant (e.g., by pressing the payment button 812), both the loyaltyaccount token and the associated payment vehicle account token aretransmitted to the merchant.

In some arrangements, the loyalty interface 800 may also include variousdepictions of payment-related services like the interface 500 discussedabove. For example, the payment related services shown in the secondfield 814 may bear a relationship to the loyalty program shown in thefirst field 802. In one embodiment, the second field 814 may include adepiction of a merchant website associated with the loyalty card suchthat the user can access an e-commerce portal provided by the associatedmerchant. Responsive to user selection of such a depiction, the user maybe brought to a further interface enabling the user to purchase variousproducts from the merchant with the user's mobile wallet.

Referring now to FIG. 9 , a flow diagram of a method 900 of dynamicallyupdating a set of functionalities accessible to a user via a mobilewallet interface according to an example embodiment is shown. Similar tothe method 300, the method 900 may be performed by one or morecomponents of FIGS. 1-2 such that reference may be made to thesecomponents in the explanation of the method 900. The description of themethod below refers to a user-default mobile wallet interface. Anexample user-default interface is the interface 500 discussed above inrelation to FIG. 5A. Accordingly, reference to various elements of theinterface 500 is made below.

As will be understood, elements of the steps 902-924 discussed below maybe performed at either the user mobile device 110 or the mobile walletcomputing system 150 depending on the implementation of the mobilewallet client application 112. Reference is made to the processor of theuser mobile device 110 performing various operations discussed below. Itshould be understood that any such operations may be performed by aprocessor of the mobile wallet computing system 150 or mobile walletcircuit 154 depending on the implementation. For example, in somearrangements, the mobile wallet client application 112 includes a nativeapplication stored in a system memory of the user mobile device 110. Thenative application may include, for example a library of functionalitiesincorporated into the user's mobile wallet by the methods describedabove as well as user interface parameters for various interfaces thatthe mobile wallet client application 112 may present to the user. Theuser may interact with the interface in any of the ways discussed aboveto communicate various preferences to the mobile wallet computing system150 or third party computing systems 160. In some arrangements, certainuser interactions cause the mobile wallet computing system 150 to updatethe native application on the user mobile device 110. For example,responsive to the user indicating a preference to incorporate aparticular functionality into the user's mobile wallet, the mobilewallet computing system 150 may transmit an updated native applicationthat incorporates the indicated functionality into the user's mobilewallet.

At process 902, the user is presented with a default mobile walletinterface. In some arrangements, the user selects the mobile walletclient application 112 from a main screen provided by the user mobiledevice 110 and is brought to the interface 500 by program logic storedin the system memory of the user mobile device 110.

In some arrangements, at least a portion of the mobile wallet clientapplication 112 is implemented at the mobile wallet computing system150. In such arrangements, the user may select the mobile wallet clientapplication 112 from a main menu of the user-computing device or via aweb browser, provide login credentials, and receive various aspects ofthe mobile wallet client application 112 from the mobile walletcomputing system 150 so that the user is presented with a mobile walletinterface on the user mobile device 110. For example, program logic andinterface contents may be downloaded from the mobile wallet computingsystem 150.

At process 904, an indication of a user interaction with the first field502 of the interface 500 is received. For example, the user may, forexample, perform a swiping action on a mobile device display within thefirst field 502, press a particular portion of the first field 502, orthe like to provide an input that is assessed by the processor of theuser mobile device 110.

At process 906, it is determined if the user selected an alternativepayment vehicle. In some arrangements, the program logic being executedby the processor of the user mobile device 110, whether a part of anative application or received from the mobile wallet computing system150, causes the processor to assess the input created by the user'sinteraction with the first field 502 using a predetermined threshold todetermine if the user has selected an alternative payment vehicle. Forexample, in some embodiments, the user must swipe the first field 502 bymore than a predetermined amount to indicate a selection of analternative payment vehicle.

At process 908, if it is determined that the user has not selected analternative payment vehicle (e.g., performed an action that is not aselection action), the program logic being executed by the processorcauses the processor to determine if the user has indicated a preferenceto view a balance associated with the default payment vehicle (e.g.,pressed the balance button 512). If so, the mobile wallet clientapplication 112 may initiate a sequence to present balance informationto the user at process 910. In some arrangements, the mobile walletclient application 112 may transmit a balance-request to the mobilewallet computing system 150 or the financial institution computingsystem 130 when the user indicates a balance-viewing preference, receivebalance data over the network 170, and use the received information topopulate a balance-viewing interface template stored at the user mobiledevice 110. In some arrangements, the mobile wallet computing system 150may request the balance information from the financial institutioncomputing system 130 when the user indicates a balance-viewingpreference, and the mobile wallet circuit 154 may transmit a balanceinterface to the user mobile device 110 over the network 170. After theuser views the balance information, the user may be again presented withthe interface 500 responsive to the user indicating a preference to nolonger view the balance information.

At process 912, if the user interaction with the first field indicated apreference to select an alternative payment vehicle, an updated firstfield is presented to the user. In various arrangements, the programlogic being executed by the processor of the user mobile device 110,whether downloaded from the mobile wallet circuit 154 or native to theuser mobile device 110, causes the processor to update the first field502 such that the first payment vehicle depiction 504 and the secondpayment vehicle depiction 510 translate in a first direction on themobile wallet interface 500 such that the second payment vehicledepiction 510 occupies the position formerly occupied by the firstpayment vehicle depiction 504. At this stage, the user may againinteract with the first field 502 to select another payment vehicle andthis step may be repeated until the user does not interact with thefirst field 502 for more than a predetermined period.

At process 914, alternative user interface parameters are retrievedbased on the updated first field. For example, by interacting with thefirst field 502 to select an alternative payment vehicle and leaving thefirst field be for more than a predetermined period (e.g., a halfsecond), the user may be issuing a command to the program logic beingexecuted by the processor to retrieve user interface parametersassociated with the selected payment vehicle. Where such parameters arestored may vary depending on the implementation. For example, theinterface parameters may be retrieved from the system memory of the usermobile device 110 when the mobile wallet client application 112 islargely a native application. Alternatively, responsive to the userissuing such a command via interaction with the first field, the usermobile device 110 may initiate communications with the mobile walletcircuit 154 to receive any updated user interfaces or parameters togenerate a user interface. In any event, the parameters may identify aset of graphics to display in the second field 516 of the mobile walletinterface 500 as well as the location for the graphics. The graphics mayrepresent any of the payment-related services discussed above.

At process 916, the user is presented with an updated mobile walletinterface. In various arrangements, the updated mobile wallet interfaceincludes an updated second field that reflects the user's selection ofthe alternative payment vehicle (e.g., the updated second field 516shown in FIG. 5B). For example, based on the interface parametersobtained at process 914, the program logic being executed by the processof the user mobile device causes the processor to generate an updatedsecond field 516 including an updated set of graphics that are presentedto the user. The graphics may be linked to a set of functionalities thatis different from the set of functionalities accessible to the user onthe first interface presented to the user at process 902. For example,the interface may include a depiction of an alternative payment-relatedservice as illustrated by FIG. 5B. In in some arrangements, such anupdated interface is downloaded (e.g., as a separate web page) from themobile wallet circuit 154.

At process 918, various indications of other user interactions arereceived and the interfaces viewable by the user are updatedaccordingly. For example, the user may select another payment vehicleand processes 902-916 may be repeated. Additionally, the user may selectvarious depictions of various payment related services (e.g., thepayment-related service depictions 518 and 520 of the interface 500discussed above in relation to FIG. 5A) and the mobile wallet clientapplication 112 may present additional interfaces to the user promptingthe user to input information pertaining to those services either bynative program logic or through communications with the mobile walletcomputing system 150. Any of the functions discussed above in relationto FIGS. 5A-8 may be performed.

At process 920, an indication of a user preference to sign off of themobile wallet is received. For example, the user may interact with themobile wallet client application in a way (e.g., by pressing the signoff button 536 of the interfaces discussed above in relation to FIGS.5A-5D) that indicates a user preference to leave the mobile wallet.Alternatively, the mobile wallet client application 112 determine thatthe user has not interacted with the mobile wallet client application112 for more than a predetermined period.

At process 922, the various user interactions with the mobile walletclient application 112 prior to the indication received at process 918are stored. For example, program logic being executed by the processorof the user mobile device 110 may cause the processor to track each userinteraction with various interfaces presented to the user duringprocesses 902-920. Each time the user interacts with any of the elementsincluded in the interface 500, for example, the mobile wallet clientapplication 112 may create an entry in a mobile wallet session datasetthat identifies the element that the user interacted with. In somearrangements, responsive to the received indication of the userpreference to sign off, this dataset is incorporated into a largerdataset tracking the user interactions of previous mobile walletsessions. In some arrangements, this larger dataset is maintained at theuser mobile device 110 in association with a native mobile wallet clientapplication 112. In some arrangements, the dataset associated with aparticular user mobile wallet session is transmitted by the user mobiledevice 110 to the mobile wallet computing system 150 for storage (e.g.,in mobile wallet database 152) when the user indicates a preference tosign off.

At process 924, mobile wallet features that are not used by the user areidentified. For example, upon storage of the user's interactions withthe mobile wallet, program logic being executed by the processor of theuser mobile device or the mobile wallet circuit 154 (e.g., via the userinterface management circuit 220) may cause the processor to assess thelarger dataset discussed above to identify any unused functionalities.For example, the mobile wallet circuit 154 or user mobile device 110 mayidentify if the user has accessed a particular feature presented on theuser-default mobile wallet interface within a predetermined time.

In some arrangements, each time the user interacts with any of theelements including in the interface 500, an entry is added to a datasettracking the users interactions with the mobile wallet in both thecurrent and previous mobile wallet sessions. Each entry, for example,may identify the interaction point that the user interacted with and atiming of the user's interaction. After an entry is added to thedataset, program logic of the mobile wallet client application 112 maycause the processor to identify, based on the information in the largerdataset, an interaction point that the user has not interacted with formore than a predetermined period of time. Such an identification mayoccur either during the user's current mobile wallet session or afterreceiving the user's preference to end the session at process 920. Aftermaking the identification, the instructions may cause the processor totake steps to remove the identified element from the interface 500. Insome arrangements, the program logic causes the process to remove theidentified functionality during the user's current mobile wallet session(e.g., the element could be removed from the interface 500 while theuser is viewing the interface 500). In some arrangements, the user'smobile wallet interface parameters are adapted after receiving theindication at process 920 such that, the next time the user accesses themobile wallet client application 112, the user is presented with anupdated mobile wallet interface not including the identified element. Insome arrangements, each time the user interacts with an interactionpoint on the mobile wallet interface 500, a notification of theinteraction is transmitted to the mobile wallet computing system 150,which may perform similar steps to identify unused functionalities.

At process 926, user mobile wallet interfaces are updated. For example,responsive to determining that the user has not accessed a particularfunctionality within a predetermined period, the user mobile device 110may reconfigure the mobile wallet interface 500 such that functionalityis no longer visible to the user. Alternatively or additionally, themobile wallet client application 112 may cause the user mobile device110 to transmit a notification indicating as much to the mobile walletcomputing system 150. In response, the mobile wallet circuit 154 (e.g.,via the user interface management circuit 210) may update the userinterface parameters such that, the next time the user activates themobile wallet client application 112, the interface 500 does not includethe unused feature. To illustrate, if the user has not engaged in a P2Ptransaction (e.g., interacted with a payment-related service depictionof a P2P payment service) for more than a predetermined period, themobile wallet circuit 154 may transmit instructions to the user mobiledevice 110 causing the removal of a depiction of a P2P service featurefrom the user's mobile wallet interface 500. In some arrangements, Theuser may re-add the removed feature, but re-configuration of the user'smobile wallet settings may require a heightened level of authenticationthan normal mobile wallet usage. For example, in addition to entering aPIN, the user may also have to input a fingerprint, username, password,and security question to change the mobile wallet settings to re-add theremoved feature. This way, the feature-removal acts as an additional wayto authenticate the user. To illustrate, if the mobile device 110 of auser who has removed the P2P feature from the mobile wallet is stolen,the thief will not be able to perform a P2P transaction (e.g., so as totransfer funds from the user's account) on the mobile wallet even if thethief knows the user's PIN.

In some arrangements, the mobile wallet circuit 154 is configured toreplace removed features with other features. For example, responsive toremoving a depiction of a particular payment-related service that hasgone unused, the mobile wallet circuit 154 may be configured to identifyan alternative third party payment-related service (e.g., through aprocess similar to the method 300 discussed above) and present that tothe user in future mobile wallet sessions. For example, if the user wasinitially presented with a P2P payment service, the P2P payment servicemay be replaced with a mobile shopping functionality (e.g., based on theuser profile generated by the registration circuit 230 discussed above).Upon identifying an alternative service, the mobile wallet circuit 154may identify the integration package associated with the identifiedservice (e.g., in the function integration circuit 210) and anygraphical elements (e.g., icons, buttons, and the like) associatedtherewith and transmit an updated set of interface parameters to theuser mobile device 110 that are configured to include the identifiedgraphical element in the user's mobile wallet interface 500. In somearrangements, the mobile wallet circuit 154 may take steps to includefunctionalities that are not included in the mobile wallet clientapplication 112 on the user mobile device 110. In such arrangements, themobile wallet circuit 154 may generate an updated software packageincluding the identified integration package stored at the mobile walletcomputing system 150 and an updated set of user interface parameters andtransmit the updated software package to the user mobile device 110 as asoftware update. Alternatively, the updated software package may bestored in association with the user's account at the mobile walletdatabase 152 such that, in future user mobile wallet sessions, the useris presented with an updated mobile wallet interface.

In various arrangements, a set of dormant, unexposed functionalities maybe included in the program logic stored at the user mobile device 110.For example, the program logic transferred to the user mobile device 110at process 310 discussed above may include not only a set offunctionalities that are to be exposed to the user on the mobile walletinterfaces, but also include other dormant functionalities that areunexposed (e.g., not shown on the mobile wallet interfaces presented tothe user). In response to determining that the user has not used anexposed functionality, the program logic may cause the processor of theuser mobile device 110 to update the mobile wallet interface parametersto replace the depiction of the unused functionality with a depiction ofone of the dormant functionalities. For example, the unexposedfunctionalities included in the user's mobile wallet may be stored in aparticular order in the mobile device 110. The order may be based on astatistical likelihood that the user would find each unexposedfunctionality to be useful. This likelihood, for example, may bedetermined by the registration circuit 230 based on the user profilediscussed above. Thus, in various arrangements, the program logic causesthe processor to expose the highest ranked functionality that is yet tobe exposed in the user's mobile wallet. For example, the program logicthat is transmitted to the user mobile device 110 may identify a set ofinteraction points to expose on the user's various mobile walletinterface, as well as a set of dormant interaction points not to exposeon the user's mobile wallet interface. Each interaction point may beassociated with an integration package is included in the softwarepackage transmitted to the user mobile device 110. Thus, upondetermining that the user has not interacted with an exposed interactionpoint, the highest-ranked dormant interaction point may be exposed bythe mobile wallet client application 112 to provide the user with accessto the functionalities provided by the associated integration package.

Referring now to FIG. 10 , a flow diagram of a method 1000 of generatinga custom credit card offer to be present to the user via a mobile walletis shown according to an example embodiment. Similar to the methods 300and 900 discussed above, the method 1000 may be performed by one or morecomponents of FIGS. 1-2 such that reference may be made to thesecomponents in the explanation of the method 1000. For example, in somearrangements, the method 1000 is performed by an identity verificationcircuit 139 and a custom credit approval circuit 138 provided at thefinancial institution computing system 130 or the mobile walletcomputing system 150. In other arrangements, the method 1000 isperformed by both components (e.g., a processor, memory, or mobilewallet circuit 154) at the mobile wallet computing system 150 and thefinancial institution computing system 130. In some arrangements, themethod 1000 is performed in solely the mobile wallet circuit 154. Insuch arrangements, the mobile wallet circuit 154 has similar structuresand performs similar functions to the custom credit approval circuit 138discussed above with respect to the financial institution computingsystem 130. In some arrangements, a portion of the steps described belowmay be performed by a processing circuit of the user mobile device 110.

It should be understood that the initiation of the method 1000 may takeon a variety of different forms. For example, in some arrangements, themethod 1000 may be periodically performed by the financial institutioncomputing system 130 and/or mobile wallet computing system 150 for eachregistered mobile wallet user. In some arrangements, the method 1000 isinitiated responsive to a new mobile wallet user indicating a preferenceto sign up for a new payment account at the financial institution duringthe mobile wallet registration process discussed above.

At process 1002, user information is received. In some arrangements, thecustom credit approval circuit 138 retrieves information pertaining tothe mobile wallet user from the financial institution accounts database134. Retrieved information may include, for example, user financialaccount information (e.g., transaction histories, account balanceinformation, and the like), user biographical information (e.g., userfamily information), and other user financial information (e.g.,information regarding a user's mortgage). In some arrangements,information pertaining to a user mobile wallet account is also retrievedfrom the mobile wallet database 152. For example, the custom creditapproval circuit 138 or mobile wallet circuit 154 may retrieveinformation pertaining to various accounts (e.g., accounts at financialinstitutions other than the financial institution associated with thefinancial institution computing system 130) that the user hasprovisioned to the user's mobile wallet.

In some arrangements, in the case of a new mobile wallet user,information may be obtained directly from the user. For example, themobile wallet circuit 154, as discussed above, may receive an indicationof a user preference to register for a new payment account at thefinancial institution. In response, the mobile wallet circuit 154 maypresent the user with various registration interfaces discussed aboverequesting, for example, scanned images of user documentation and thelike. Alternatively, the mobile wallet circuit 154 may notify thefinancial institution computing system 130, which (e.g., via theidentity verification circuit 139) may in turn transmit the registrationinterfaces to the user mobile device 110 and receive information inputby the user into the interfaces.

In response to receiving user-input information, the identityverification circuit 139 may process the received information toascertain the new mobile wallet user's identity. For example, if theuser captured an image of a driver's license, the identity verificationcircuit 139 may use an image-processing algorithm to extract varioususer attributes (e.g., name, address, date of birth, etc.) from theimage. Based on the extracted user attributes, the identity verificationcircuit 139 may retrieve additional user information from various othersources. For example, the identity verification circuit 139 may requesta credit report from a credit bureau or other data service that accessesvarious government databases to formulate a profile of user information.As discussed above, this profile may be used to generate verificationqueries to transmit to the user mobile device 110 to be used to verifythe user.

In some arrangements, in both the case of a new mobile wallet user and apreviously registered mobile wallet user, additional information may bereceived from the user mobile device 110. For example, various APIsincluded in the third party integration circuit 114 of the mobile walletclient application 112 may configure the mobile wallet clientapplication 112 to retrieve user data stored in association with thirdparty client applications 116 and transmit the information to thefinancial institution computing system 130. Transmitted information mayinclude, for example, user social media information, user contenthistory (e.g., content that the user has accessed by a third partyclient application 116 associated with a content provider), and thelike.

At process 1004, the user information received at process 1002 isassessed against predetermined criteria to determine the user'seligibility for a credit card offer. In some arrangements, the customcredit approval circuit 138 assesses information pertaining to afinancial account held by the user at the financial institution. Forexample, in cases where the user has an account at the financialinstitution, the custom credit approval circuit 138 may assess the ageof the user's financial account, as well as account balance trends todetermine the user's eligibility for a credit card offer. In somearrangements, in cases of new mobile wallet users registering for anaccount, the custom credit approval circuit 138 may perform such ananalysis on information contained in, for example, a credit reportreceived from a credit bureau or other user information report.Information obtained pertaining to the user may be compared to thresholdpreconfigured by financial institution personnel to determine the user'seligibility for a credit card offer.

In some arrangements, the predetermined criteria used custom creditapproval circuit 138 to access the received user information involves aprocess to pre-underwrite a customer for a certain level of credit. Thisprocess may be performed by accessing information stored at thefinancial institution computing system 130 or received from a creditbureau or other data sources. For example, for a user already holding achecking account at the financial institution, if the checking accountreceives a direct deposit from an employer, the custom credit approvalcircuit 138 may identify this as a verification of the user's income andemployment. Alternatively, in the case of a new mobile wallet userregistering for a new account, the custom credit approval circuit 138may receive a scanned image of a recent paycheck from the user to serveas a verification of employment.

Having verified the user's employment or sources of income, the customcredit approval circuit 138 may further assess user account balancetrends (e.g., of a checking account of a user) to project the user'sability to repay a given level of credit card debt. Further, based onthe user's transaction history stored in the financial institutionaccounts database 134 or obtained through a credit report or othermeans, the custom credit approval circuit 138 may project a number oftransactions that the user will use a new credit card for. Such aprojection may be based on, for example, information in the user'stransaction history describing payments made by the user to anotherfinancial institution for another credit card held by the user. Forexample, based on the amount of such payments, the custom creditapproval circuit 138 may generate a projected number of usertransactions. Further, such a projection may also incorporate historicaldata of other users having similar personal information (e.g., credithistories and the like) to the user. Based on this projected transactionnumber, a projected profitability for the financial institution of thenew user credit card may be determined. If the projected profitabilityis above a predetermined threshold, for example, the financialinstitution may pre-underwrite the customer for a credit card.

At process 1006, it is determined if the user is eligible for a creditcard offer. For example, if it is determined at process 1004 that theuser information does not meet predetermined criteria for a credit cardoffer, the custom credit approval circuit 138 may determine that theuser does not qualify for a credit card offer. In such a case, themethod 1000 may end.

If the user is determined to be eligible for the credit card offer, aset of credit offer terms is selected for the customer in somearrangements. The custom credit approval circuit 138 may assign any of aseries of standardized sets of credit offer terms to the customer. Thestandardized sets may differentiated from one another by the credit cardterms (e.g., interest rates, credit limits, etc.) that they include. Forexample, a first standardized set may include a lower interest rate anda higher credit limit than another standardized set. In variousarrangements, each standardized set may have a set of qualificationsassociated therewith. For example, the low interest rate set discussedabove may require that the user have an existing account at thefinancial institution of a certain age, meet certain account balancethreshold requirements, have a certain stream of positive cash flows(e.g., deposits) into the existing account, and the like. Accordingly,the user is eligible, the custom credit authorization circuit 138 maycompare information associated with the user's existing account with thequalifications to determine which standardized set of terms that theuser qualifies for.

At process 1008, if a customer is determined to qualify for a creditcard offer, a user credit preference is identified. In variousarrangements, the custom credit approval circuit 138 may add to ormodify the standardized set of terms selected for the user toindividually tailor the credit card offer to the user. In this regard,the custom credit approval circuit 138 assesses any availableinformation pertaining to the user (e.g., stored in the financialinstitution accounts database 134 or obtained from third parties likesocial media networks and the like) to determine at least onecharacteristic of a credit card that is tailored specifically to themobile wallet user. In various examples, the particularizedcharacteristic may be a financial reward category to associate with thecredit card. To illustrate, the custom credit approval circuit 138 mayassess the user's transaction history and determine that the user makesfrequent purchases at a particular grocery store. In response to makingsuch a determination, the custom credit approval circuit 138 maygenerate an individually-tailored financial reward program for the userwhereby the user can earn rewards (e.g., cash back) by using the creditcard to make purchases at the grocery store. Similar rewards may begenerated using other forms of user information. For example, if thecustom credit approval circuit 138 receives third party informationpertaining to the user (e.g., from a social media platform), anddetermines that the user frequently makes posts pertaining to aparticular topic (e.g., vacations), the custom credit approval circuit138 may generate a reward pertaining to that topic (e.g., an airlinemiles reward).

In some arrangements, the user credit preference is based on anidentified financial goal of the user. User financial goals may berelated to user payment obligations or prospective purchases. Forexample, if the user's account information stored in the accountsdatabase 134 indicates that the user is currently paying off a mortgage,the custom credit approval circuit 138 may determine that the user has acredit preference for a credit card reward that assists the user inpaying off the mortgage (e.g., for each dollar the user spends with thenew credit card, the user may earn a fixed credit towards a mortgagepayment). Other rewards programs may similarly assist the user withother payment obligations (e.g., car loans, lines of credit, businessloans, bill payments, and the like). In another example, the customcredit approval circuit 138 may identify a user prospective purchasebased on received social media information and/or information stored inthe accounts database 134. For example, if the information stored in theaccount database 134 indicates that the user is young and recentlymarried, the custom credit approval circuit 138 may identify a homepurchase as a prospective purchase for the user. An associated creditpreference may be generated that enables the user to build up credit toqualify for a mortgage at a more favorable rate (e.g., by using the newcredit card and making timely payments over a certain period of time,the user may qualify for a particular home loan). In another example,received social media information may indicate a prospective userpurchase. If the received social media information indicates the userlikes to travel, the custom credit approval circuit 138 may identify atravel-related financial reward to facilitate the user's traveling(e.g., airline rewards, hotel rewards, and the like).

In some arrangements, user credit preferences may include other aspectsof the credit card offer. For example, if the custom credit approvalcircuit 138 determines that the user has a credit card account withanother financial institution, the user credit preference may be abalance transfer offer at a particular interest rate. In variousarrangements, the custom credit approval circuit 138 may determine thatthe user has a credit account at another financial institution based onthe user's transaction history stored at the accounts database 134. Forexample, if the user makes regular payments to another financialinstitution, this may be an indication of another user credit account.Alternatively or additionally, the custom credit approval circuit 138may identify an additional user credit account based on a credit reportreceived from a credit bureau. Alternatively or additionally, the usermay be able to take a picture of an existing credit card and transmitthat information to the financial institution computing system 130 viathe user's mobile wallet (e.g., in the registration process discussedabove) to make the financial institution computing system 130 aware ofanother user credit card.

At process 1010, credit card offer terms are generated. Credit cardoffer terms may include, for example, general credit terms (e.g.,interest rates, credit limits, rewards and the like) as well as the usercredit preference generated at process 1008. In various arrangements,the custom credit approval circuit 138 generates credit card offer termsbased on the information retrieved at process 1002. For example, basedon various criteria met by the user's financial institution accountmaintained at the financial institution accounts database 134, thecustom credit approval circuit 138 may generate a user interest rate andcredit limit for a credit card to be offered to the user. Additionally,based on the identification of another user credit card, the customcredit approval circuit 138 may generate terms for an account balancetransfer (e.g., for a particular amount at a particular interest rate)whereby the user can pay down the balance associated with the othercredit card account with the new credit card offered by the financialinstitution. Additionally, the custom credit approval circuit 138 maygenerate a individually-tailored financial reward to offer the user. Forexample, if, based on information stored in the financial institutionaccounts database 134, the custom credit approval circuit 138 determinesthat the user is currently paying off a mortgage, the custom creditapproval circuit 138 may generate a reward that assists the user inpaying down the mortgage if the user uses the new credit card.

In various arrangements, in addition to determining the terms of thecredit card to offer the user, the custom credit approval circuit 138also generates a graphical depiction of the generated terms (or a set ofmobile wallet interface parameters configured to cause the user mobiledevice 110 to present the user with such a depiction) at process 1010.For example, based on the generated terms, the custom credit approvalcircuit 138 may retrieve content (e.g., stored in a content databaseassociated with the financial institution computing system 130 or aseparate server system) that depicts the new credit card. The retrievedcontent may, for example, depict what a physical credit card would looklike if it was issued to the user (e.g., include at least a portion ofan account number) and depict the terms of the credit card offer to theuser.

In some arrangements, the custom credit approval circuit 138 transmitsdata indicating the terms of the credit card offer. The data may bespecifically formatted to induce a response by the mobile wallet clientapplication 112 upon receipt. Upon receipt, the user mobile device 110may incorporate the terms (e.g., as a listing) of the credit card offerinto the user's mobile wallet interface as exemplified in FIG. 12 below.The user mobile device 110 may also present the user with a plurality ofcredit card display options that may be selectable by the user. Forexample, the user may be able to customize how the new credit card maybe displayed upon the user's activation of the credit card options. Theoptions may include, for example, the text of a user-generated name forthe credit card, a numerical representation, a color scheme associatedwith the card, and the like. It should be noted that the user maysimilarly reconfigure the appearance of any graphical depiction of anypayment vehicle (e.g., by hitting the settings button 538). Upon theuser's selection of a particular option, the mobile wallet clientapplication 112 may update the user's mobile wallet interfaces toinclude a depiction in accordance with the user's selected option.

At process 1012, a digital user credit card account is created. In somearrangements, once the user credit card offer terms are generated, thecustom credit approval circuit 138 creates an entry in the financialinstitution accounts database 134 for the user. User identificationinformation may be stored in association with the generated credit cardoffer terms as if the user has activated a credit card account with thegenerated terms. The custom credit approval circuit 138 may generate anaccount number and associate that number with the generated terms.Additionally, at this stage, the custom credit approval circuit 138 maystore the digital user credit card account in association with aninactive status indicator. In various arrangements, the inactive statusindicator may prevent the account from being used in any transactionuntil an activation preference is received from the user. Additionally,after creating the digital credit account, the custom credit approvalcircuit 138 may transmit a notification to the account managementcircuit 136 to initiate a sequence to generate a physical (e.g.,plastic) credit card to be mailed to the new mobile wallet user for aphysical card activation that can be performed separately from a digitalactivation via the user's mobile wallet.

At process 1014, a sequence is initiated to generate a token for the newcustomer credit card. In some arrangements, the custom credit approvalcircuit 138 transmits the newly-generated account number over thenetwork 170 to the token service provider computing system 140. Invarious arrangements, the account number is transmitted in such a waythat the account number is identified as a pre-approved digital creditcard account. For example, a specifically formatted indicator may betransmitted to the token service provider computing system 140 thatidentifies the account as a preapproved digital account. Such anindicator may cause the token service provider computing system 140 toprovision a token for the digital credit card account even though theaccount has not yet been activated by the user. For example, there maybe an arrangement between the financial institution and the tokenservice provider whereby the token service provider agrees to configurethe token service provider computing system 140 to generate a token foraccount numbers transmitted in association with such an indicator.Accordingly, responsive to receiving the digital credit card accountnumber, the token service provider computing system 140 generates atoken for the account number and stores the token in a database (e.g., atoken vault). The generated token is the transmitted back, for example,to the financial institution computing system 130 where it is stored inassociation with the digital user credit card account created at process1012.

In some arrangements, process 1014 is omitted from the method 1000. Forexample, the new digital credit card account may be tokenized after theuser indicates a preference to activate the account from within theuser's mobile wallet (e.g., during the method 1100 discussed below).

At process 1016, the credit card offer terms and any tokens aretransmitted. In some arrangements, the terms and token are transmittedover the network 170 to the mobile wallet computing system 150. In somearrangements, the custom credit approval circuit 138 communicates thegenerated offer terms to the mobile wallet circuit 154 for presentationto a user by methods described below. It should be understood that, insome arrangements, where, for example, the custom credit approvalcircuit 138 is provided in the mobile wallet circuit 154, the process1016 may be omitted form the method 1000.

Referring now to FIG. 11 , a flow diagram of a method 1100 of activatinga user credit card for instant use in a user mobile wallet is shownaccording to an example embodiment. Similar to the methods 300 and 900discussed above, the method 1000 may be performed by one or morecomponents of FIGS. 1-2 such that reference may be made to thesecomponents in the explanation of the method 1100.

At process 1102, the credit card offer is presented to the user. In somearrangements, the custom credit approval circuit 138 initiates asequence to communicate the credit offer to the user. This sequence mayboth provide the user with a push notification as well as result in theuser being able to view the offered credit card in the user's mobilewallet. Such a process may involve a number of steps. First, afterapproving the user for a credit card offer and generating terms via theprocess 1000 discussed above, the custom credit approval circuit 138 maygenerate a push notification of the credit card offer. To do this, thecustom credit approval circuit may construct a message containing atleast some of the terms of the credit card offer discussed above. Toensure that the message is directed to the user mobile device 110, thecustom credit approval circuit 138 may retrieve a unique identifierassociated with the user's mobile wallet client application 112 from thefinancial institution accounts database 134 and package the uniqueidentifier with the generated message. The custom credit approvalcircuit 138 may then transmit the package to a push notification serviceassociated with the mobile wallet computing system 150, which may inturn transmit the push notification to the user mobile device 110.Alternatively, the financial institution computing system 130 maytransmit the message to the mobile wallet computing system 150, whichmay in turn initiate communications with push notification service totransmit the notification to the user mobile device 110. Alternatively,there may be no push notification service, and the mobile walletcomputing system 150 (e.g., via the mobile wallet circuit 154) orfinancial institution computing system 130 (e.g., via the accountmanagement circuit 136) transmits the push notification directly to theuser mobile device 110.

In various arrangements, the mobile wallet computing system 150 may havean agreement with a push notification service whereby the pushnotification service may provide an API and/or SDK to be integrated intothe mobile wallet client application 112 to facilitate the mobile walletclient application 112 communicating with the push notification service.Also in accordance with the agreement, when the user installs the mobilewallet client application 112 on the user mobile device 110, adevice-specific unique identifier is assigned to the user by the mobilewallet computing system 150 or the app store from which the applicationwas downloaded. This unique identifier is provided to the pushnotification service and stored such that, when the push notificationservice receives the message generated by the financial institutioncomputing system 130 containing the credit card offer terms and theuser's unique identifier, the push notification service “pushes” themessage to the user mobile device 110. In various arrangements, themobile wallet computing system 150 can perform any of the operationsdiscussed above with respect to the push notification service.

When the user mobile device 110 receives the message generated by thefinancial institution computing system 130, the operating system orother software library of the user mobile device 110 may call a responsefunction of the mobile wallet client application 112. The responsefunction causes a viewable notification or message to be viewable on theuser mobile device 110. The message may notify the user of thepre-approval for the credit card offer. Additionally, responsive toreceiving the push notification, the mobile wallet client application112 may update the user's interface parameters to include a graphicaldepiction of the terms of the credit card offer included in the receivedpush notification. For example, the native mobile wallet clientapplication 112 on the user mobile device 110 may include a credit cardoffer template. Responsive to receiving the push notification, thecredit card template may be populated with the offer terms contained inthe push notification and included in the first field of the user'smobile wallet interface. An example interface included such a depictionwill be discussed below in relation to FIG. 12 .

In another example, responsive to receiving the push notification, themobile wallet client application 112 may transmit a credit-offernotification to the mobile wallet computing system 150 to receive moreinformation pertaining to the credit card offer. The mobile walletcircuit 154 may transmit credit card offer information received from thefinancial institution computing system 130 to the user mobile device 110responsive to receiving the credit-offer notification. The user mobiledevice 110 may receive the credit offer information, and, via the mobilewallet client application 112, incorporate a depiction of the creditoffer information into the user's mobile wallet interfaces. As will beappreciated, this sequence (i.e. the mobile wallet computing system 150transmitting information to the user mobile device 110) may be performedwithout the push notification process. For example, in some embodiments,the user is not notified of being pre-approved for the credit cardoffer. Rather, the credit card offer simply shows up as a paymentvehicle in the first field of the user's mobile wallet interface, and isviewable by the user the next time the user activates the mobile walletclient application 112.

In some arrangements, process 1102 is performed when the user activatesa newly-installed mobile wallet client application 112 on the usermobile device. For example, after a new mobile wallet user indicates apreference to register for a new account with the financial institution,performs the registration processes discussed above, and a new digitalcredit card account is created for the user via the method 1000discussed above, the new user's mobile wallet is preconfigured toinclude a depiction of the user's new digital credit card account. Thus,upon activation of the mobile wallet client application 112, the usermay be presented with the ability to activate the new digital creditaccount. This may occur well before the user receives any physicalcredit cards associated with the new account from the financialinstitution in the mail.

At process 1104, an indication of a user interaction with the presentedcredit card offer is received. For example, the user may view a mobilewallet interface (such as the interface 1200 discussed below in relationto FIG. 12 ) that includes the credit card offer. The first field ofthis mobile wallet interface may enable the user to indicate apreference as to the credit card offer (e.g., accept or reject theoffer). The user may interact with the interface to indicate such apreference and, by so doing, provide inputs to the program logic of themobile wallet client application 112 being executed by the processor ofthe user mobile device 110. The inputs may cause the user mobile device110 to communicate the indicated preference to the financial institutioncomputing system 130 over the network 170 (e.g., via an API) or themobile wallet computing system 150. The mobile wallet computing system150 may in turn communicate the user's indicated preference to thefinancial institution computing system 130.

At process 1106, it is determined if the user accepted the offer basedon the preference received at process 1104. For example, the inputprovided by the user as a result of interacting with the credit cardoffer may vary depending on whether the user indicated an acceptancepreference or a declination preference. Thus the financial institutioncomputing system 130 (e.g., by the custom credit approval circuit 138 orthe account management circuit 136) may determine if the user acceptedthe offer based on the nature the communication received from either theuser mobile device 110 or the mobile wallet computing system 150.

At process 1108, in response to the user accepting the credit cardoffer, a credit card activation sequence is initiated. For example,responsive to receiving the notification of the user's acceptance of theoffer, the account management circuit 136 may update the accountdatabase 134 to activate the user's new account. For example, theaccount management circuit 136 may remove the inactive status indicatordiscussed above from the user's digital credit card account to enablethe account to be used for the completion of transactions. Additionally,after activating the user's account, the financial institution computingsystem 130 may notify the mobile wallet computing system 150.

In some arrangements, responsive to the user accepting the offer, asequence to tokenize the digital credit card account is performed. Thefinancial institution computing system 130 may perform similar steps asthose discussed above in relation to process 1014 of the method 1000discussed above and transmit any received tokens to the mobile walletcomputing system 150.

At process 1110, the user's mobile wallet parameters are updated toreflect the activation of the new user credit card. In somearrangements, responsive to receiving an indication that the user's newcredit card has been activated by the financial institution computingsystem 130, the mobile wallet circuit 154 may transmit an activationsignal to the user mobile device 110. The activation signal mayconfigure the mobile wallet client application 112 to incorporatevarious features into the mobile wallet interface associated with thenew credit card. For example, the mobile wallet interface may include apayment button enabling the user to engage in mobile wallet transactionsusing the newly activated credit account and include the token receivedfrom the financial institution computing system 130.

It should be noted that, in accordance with the systems and methodsdisclosed herein, the processes 1104-1110 of the method 1000 discussedabove (i.e., the time period between the user indicating a preference toactivate the digital credit card account and the user's mobile walletbeing updated to enable the user to perform a transaction with anaccount) take a relatively short amount of time to complete. In someembodiments, processes 1104-1110 take place in a matter of ten minutesor less. In other embodiments, processes 1104-1110 take a matter takeplaces in a matter of five minutes or less. In yet still otherembodiments, processes 1104-1110 take place in under ten seconds. In yetstill other embodiments, processes 1104-1110 take place in a time periodbetween two to four seconds.

To summarize the foregoing, in operation, the systems and methodsdisclosed herein enable the following example process to be performedfor a user to activate a new account at the financial institution aswell as a mobile wallet. A user visits a website associated with thefinancial institution and/or mobile wallet provider via the user mobiledevice 110 and indicates a preference to register for an account. Inresponse, the mobile wallet computing system 150 transmits variousinformation requests to the user. The requests may ask the user forimages of a driver's license as well as an image of the user's face. Theuser activates a camera on the mobile device 110, takes the requestedimages, inputs any additional requested information (e.g., socialsecurity number), and causes the user mobile device 110 to transfer theuser-input information to the mobile wallet computing system 150 and/orfinancial institution computing system 130. In turn, the user's identityis verified. For example, the financial institution computing system 130may verify the authenticity of the user's driver's license by comparingthe image of the user's license to a template and the image of theuser's face, request information from other sources (e.g., creditbureaus, social media websites, mobile phone carriers, and the like),and transmit verification queries to the user based on the requestedinformation to verify the identity of the user. Having verified theuser's identity, the financial institution computing system 130 mayrequest additional information from the user and/or other sources topre-populate a credit application. Using the credit application data,the financial institution computing system 130 pre-underwrites thecustomer for a credit card by assessing the user's information withpredetermined criteria. The financial institution computing system 130then creates a digital credit card account number for the user,tokenizes the account number, and updates the user's mobile walletinterface parameters such that a depiction of the digital credit cardaccount number shows up upon the user activating the user's new mobilewallet. The depiction may include an activation functionality enablingthe user to activate the digital credit card account. Upon the useractivating the account, the account is available for use within a matterof seconds.

Technically and beneficially, this process streamlines the process ofactivating a credit card. Rather than receiving a paper application inthe mail or having to initiate the application process, the user isnotified that they have been pre-approved. What is more, because thenotification is linked to the user's mobile wallet client application112, the user can immediately accept the offer by activating the mobilewallet client application (e.g., by pressing the received pushnotification), manipulating the mobile wallet interface to view thecredit card offer (e.g., swiping the first field), and hitting “accept.”Upon hitting “accept”, the offered credit card is almost immediatelyavailable for use. In other words, rather than being notified of acredit card offer, having to fill out an application, and wait for anapproval, the user activates a credit card and can use it almostinstantly.

Turning now to FIG. 12 , an example mobile wallet interface 1200including a credit card offer displayed by the user mobile device 110 isshown according to an example embodiment. In various arrangements, theinterface 1200 is what may be presented to a mobile wallet user afterthe user receives the push notification discussed above. In somearrangements, the interface may be shown irrespective of whether theuser receives a push notification. For example, the interface 1200 maybe viewable by the user after the mobile wallet computing system 150receives the credit card offer terms (e.g., from either the financialinstitution computing system 130 or a custom credit approval circuit 138at the mobile wallet computing system 150). For example, the interface1200 may be viewable after user mobile device 110 receives credit offerinformation from either the mobile wallet circuit 154 or the financialinstitution computing system 130.

As shown, the mobile wallet interface 1200 includes a first field 1202,a second field 1214, and a third field 1220. The third field 1220includes elements 1222-1236 similar to those elements 528-542 discussedabove with respect to the interface 500 shown in FIG. 5A. As shown, thefirst field 1202 includes a payment vehicle depiction 1204, a creditcard offer depiction 1206, a terms window 1208, an acceptance button1210, and a decline button 1212. The payment vehicle depiction 1204 mayinclude a graphical depiction of a payment vehicle that the user hasprovisioned for use in a mobile wallet. In various arrangements, theuser may select the payment vehicle depicted by the depiction 1204 bymanipulating (e.g., swiping, pressing, and the like) the first field1202 as discussed above. The credit card offer depiction 1206 presentsthe user with a depiction of a credit card being offered to the user. Asshown, the depiction 1206 includes a description of a characteristic ofthe credit card particularly selected for the user (e.g., based on theuser credit preference identified by the custom credit approval circuit138 during the method 1000 discussed above with respect to FIG. 10 ).The terms window 1208 presents the user with the terms associated withthe offered credit card. By pressing either the acceptance button 1210or the decline button 1212, the user can indicate a preference as towhether the user wishes to accept the offered credit card. In responseto the user pressing the acceptance button 1210, the user mobile device110 may transmit an acceptance notification to the mobile walletcomputing system 150 or financial institution computing system 130,which may perform steps (e.g., processes 1108 and 1110 discussed abovewith respect to FIG. 11 ) to enable the user to perform mobile wallettransactions with the new credit card. In response to the user selectingthe decline button 1212, the user mobile device 110 may transmit adenial notification to the mobile wallet computing system 150 orfinancial institution computing system 130, which may be configured toupdate the user's mobile wallet account so that the offered credit cardis no longer viewable by the user.

As shown, the interface 1200 includes a second field 1214 that includesa depiction of a first payment service 1216 and a depiction of a secondpayment service 1218. The depictions 1216 and 1218 may be similar to thedepictions of the payment services discussed above with respect to FIGS.5A-5B. In some arrangements, responsive to user selection of either ofthe depictions 1216 and 1218, the user may be brought to differentinterfaces informing the user about the services depicted. Even thoughthe credit card has not yet been activated, and is thus unavailable foruse with the depicted payment service, the depictions 1216 and 1218 maybe services that would be compatible with the offered credit card ifaccepted by the user. Thus, the interface 1200 presents the users withadditional functionalities that may be available to the user via themobile wallet if the user activates the offered credit card.

The embodiments described herein have been described with reference todrawings. The drawings illustrate certain details of specificembodiments that provide the systems, methods and programs describedherein. However, describing the embodiments with drawings should not beconstrued as imposing on the disclosure any limitations that may bepresent in the drawings.

It should be understood that no claim element herein is to be construedunder the provisions of 35 U.S.C. § 112(f), unless the element isexpressly recited using the phrase “means for.”

As used herein, the term “circuit” may include hardware structured toexecute the functions described herein. In some embodiments, eachrespective “circuit” may include machine-readable media for configuringthe hardware to execute the functions described herein. The circuit maybe embodied as one or more circuitry components including, but notlimited to, processing circuitry, network interfaces, peripheraldevices, input devices, output devices, sensors, etc. In someembodiments, a circuit may take the form of one or more analog circuits,electronic circuits (e.g., integrated circuits (IC), discrete circuits,system on a chip (SOCs) circuits, etc.), telecommunication circuits,hybrid circuits, and any other type of “circuit.” In this regard, the“circuit” may include any type of component for accomplishing orfacilitating achievement of the operations described herein. Forexample, a circuit as described herein may include one or moretransistors, logic gates (e.g., NAND, AND, NOR, OR, XOR, NOT, XNOR,etc.), resistors, multiplexers, registers, capacitors, inductors,diodes, wiring, and so on).

The “circuit” may also include one or more processors communicativelycoupled to one or more memory or memory devices. In this regard, the oneor more processors may execute instructions stored in the memory or mayexecute instructions otherwise accessible to the one or more processors.In some embodiments, the one or more processors may be embodied invarious ways. The one or more processors may be constructed in a mannersufficient to perform at least the operations described herein. In someembodiments, the one or more processors may be shared by multiplecircuits (e.g., circuit A and circuit B may comprise or otherwise sharethe same processor which, in some example embodiments, may executeinstructions stored, or otherwise accessed, via different areas ofmemory).

Alternatively or additionally, the one or more processors may bestructured to perform or otherwise execute certain operationsindependent of one or more co-processors. In other example embodiments,two or more processors may be coupled via a bus to enable independent,parallel, pipelined, or multi-threaded instruction execution. Eachprocessor may be provided as one or more general-purpose processors,application specific integrated circuits (ASICs), field programmablegate arrays (FPGAs), digital signal processors (DSPs), or other suitableelectronic data processing components structured to execute instructionsprovided by memory. The one or more processors may take the form of asingle core processor, multi-core processor (e.g., a dual coreprocessor, triple core processor, quad core processor, etc.),microprocessor, etc. In some embodiments, the one or more processors maybe external to the apparatus, for example the one or more processors maybe a remote processor (e.g., a cloud based processor). Alternatively oradditionally, the one or more processors may be internal and/or local tothe apparatus. In this regard, a given circuit or components thereof maybe disposed locally (e.g., as part of a local server, a local computingsystem, etc.) or remotely (e.g., as part of a remote server such as acloud based server). To that end, a “circuit” as described herein mayinclude components that are distributed across one or more locations.

An exemplary system for providing the overall system or portions of theembodiments might include a general purpose computing computers in theform of computers, including a processing unit, a system memory, and asystem bus that couples various system components including the systemmemory to the processing unit. Each memory device may includenon-transient volatile storage media, non-volatile storage media,non-transitory storage media (e.g., one or more volatile and/ornon-volatile memories), etc. In some embodiments, the non-volatile mediamay take the form of ROM, flash memory (e.g., flash memory such as NAND,3D NAND, NOR, 3D NOR, etc.), EEPROM, MRAM, magnetic storage, hard discs,optical discs, etc. In other embodiments, the volatile storage media maytake the form of RAM, TRAM, ZRAM, etc. Combinations of the above arealso included within the scope of machine-readable media. In thisregard, machine-executable instructions comprise, for example,instructions and data which cause a general purpose computer, specialpurpose computer, or special purpose processing machines to perform acertain function or group of functions. Each respective memory devicemay be operable to maintain or otherwise store information relating tothe operations performed by one or more associated circuits, includingprocessor instructions and related data (e.g., database components,object code components, script components, etc.), in accordance with theexample embodiments described herein.

It should also be noted that the term “input devices,” as describedherein, may include any type of input device including, but not limitedto, a keyboard, a keypad, a mouse, joystick or other input devicesperforming a similar function. Comparatively, the term “output device,”as described herein, may include any type of output device including,but not limited to, a computer monitor, printer, facsimile machine, orother output devices performing a similar function.

Any foregoing references to currency or funds are intended to includefiat currencies, non-fiat currencies (e.g., precious metals), andmath-based currencies (often referred to as cryptocurrencies). Examplesof math-based currencies include Bitcoin, Litecoin, Dogecoin, and thelike.

It should be noted that although the diagrams herein may show a specificorder and composition of method steps, it is understood that the orderof these steps may differ from what is depicted. For example, two ormore steps may be performed concurrently or with partial concurrence.Also, some method steps that are performed as discrete steps may becombined, steps being performed as a combined step may be separated intodiscrete steps, the sequence of certain processes may be reversed orotherwise varied, and the nature or number of discrete processes may bealtered or varied. The order or sequence of any element or apparatus maybe varied or substituted according to alternative embodiments.Accordingly, all such modifications are intended to be included withinthe scope of the present disclosure as defined in the appended claims.Such variations will depend on the machine-readable media and hardwaresystems chosen and on designer choice. It is understood that all suchvariations are within the scope of the disclosure Likewise, software andweb implementations of the present disclosure may be accomplished withstandard programming techniques with rule based logic and other logic toaccomplish the various database searching steps, correlation steps,comparison steps and decision steps.

The foregoing description of embodiments has been presented for purposesof illustration and description. It is not intended to be exhaustive orto limit the disclosure to the precise form disclosed, and modificationsand variations are possible in light of the above teachings or may beacquired from this disclosure. The embodiments were chosen and describedin order to explain the principals of the disclosure and its practicalapplication to enable one skilled in the art to utilize the variousembodiments and with various modifications as are suited to theparticular use contemplated. Other substitutions, modifications, changesand omissions may be made in the design, operating conditions andarrangement of the embodiments without departing from the scope of thepresent disclosure as expressed in the appended claims.

What is claimed is:
 1. A computer-implemented method, comprising:presenting, by a mobile device, an initial user interface to a user, theinitial user interface including: a first field including a firstgraphical depiction of a first object associated with the user; and asecond field including a second graphical depiction; receiving, by themobile device, an indication of a user interaction with the first field;and dynamically updating, by the mobile device, the initial userinterface responsive to determining that the user interaction is a userselection of a second object to create an updated user interfaceincluding: an updated first field including a depiction of the secondobject; and an updated second field including a third graphicaldepiction.
 2. The method of claim 1, wherein the first object is adefault source account of the user.
 3. The method of claim 2, whereinthe first field of the initial user interface also includes a firstinteraction point configured to receive a user preference.
 4. The methodof claim 3, wherein the second object is an object that has not yet beenprovisioned, wherein the updated first field includes a secondinteraction point that is configured to receive a user preference toprovision the second object.
 5. The method of claim 3, wherein thesecond object is a deactivated object, wherein the updated first fieldincludes a notification informing the user that the second object hasbeen deactivated.
 6. The method of claim 1, wherein the second graphicaldepiction is configured to receive a user preference to perform at leastone of the following actions: view a history associated with the firstobject, set at least one preference with respect to the first object, oraccess at least one graphical depiction not involving the user.
 7. Themethod of claim 6, wherein the first object differs from the secondobject in at least one respect, and wherein a difference between thesecond graphical depiction and the third graphical depiction is based onthe at least one respect.
 8. The method of claim 7, wherein both theinitial user interface and the updated user interface include anidentical third field, the third field containing a third interactionpoint configured to enable the user to indicate a preference to performat least one non-transaction function.
 9. The method of claim 7, whereinthe first object is a debit card and the second object is a gift card,and wherein the second graphical depiction depicts a person-to-person(P2P) transfer service and the third graphical depiction depicts ashopping functionality.
 10. The method of claim 9, wherein each of thesecond graphical depiction and third graphical depictions constitutes anadditional interaction point configured to receive a user preference toaccess each of the second and the third graphical depictions,respectively.
 11. The method of claim 10, further comprising: receiving,by the mobile device, an indication that the user prefers not tointeract further with the initial user interface or the updated userinterface; ending, by the mobile device, a user session responsive toreceiving the indication that the user prefers not to interact furtherwith the initial user interface or the updated user interface; storing,by the mobile device, information pertaining to user interaction with atleast one interaction point presented to the user during the usersession; determining, by the mobile device, based on the storedinformation, that the user has not interacted with a particularinteraction point on the initial user interface for more than apredetermined period of time; and reconfiguring, by the mobile device,the updated user interface to not include the particular interactionpoint in a future user session.
 12. A mobile device, comprising: anetwork circuit structured to communicate data to and from a computingsystem; an input/output device structured to exchange data with a user;and a client application circuit coupled to the network circuit and theinput/output device, the client application circuit structured to:present, via the input/output device, an initial user interface to theuser, the initial user interface including: a first field including afirst graphical depiction of a first object associated with the user;and a second field including a second graphical depiction; receive, viathe input/output device, an indication of a user interaction with thefirst field; and dynamically update the initial user interfaceresponsive to determining that the user interaction is a user selectionof a second object to create an updated user interface including: anupdated first field including a depiction of the second object; and anupdated second field including a third graphical depiction.
 13. Themobile device of claim 12, wherein the first field of the initial userinterface also includes a first interaction point configured to receivea user preference.
 14. The mobile device of claim 13, wherein the secondobject is an object that has not yet been provisioned, wherein theupdated first field includes a second interaction point configured toreceive a user preference to provision the second object.
 15. The mobiledevice of claim 13, wherein the first object differs from the secondobject in at least one respect, wherein a difference between the secondgraphical depiction and the third graphical depiction is based on the atleast one respect.
 16. The mobile device of claim 12, wherein both theinitial user interface and the updated user interface include anidentical third field, the third field containing a third interactionpoint configured to enable the user to indicate a preference to performat least one non-transaction function.
 17. A non-transitory computerreadable media having computer-executable instructions embodied thereinthat, when executed by at least one processor of a mobile device, causethe at least one processor to perform operations comprising: presentingan initial user interface to a user, the initial user interfaceincluding: a first field including a first graphical depiction of afirst object associated with the user; and a second field including asecond graphical depiction; receiving an indication of a userinteraction with the first field; and dynamically updating the initialuser interface responsive to determining that the user interaction is auser selection of a second object to create an updated user interfaceincluding: an updated first field including a depiction of the secondobject; and an updated second field including a third graphicaldepiction.
 18. The non-transitory computer readable media of claim 17,wherein the first object includes a default source account of the user.19. The non-transitory computer readable media of claim 18, wherein thefirst field of the initial user interface also includes a firstinteraction point configured to receive a user preference.
 20. Thenon-transitory computer readable media of claim 18, wherein the secondobject is a deactivated object, and wherein the updated first fieldincludes a notification informing the user that the second object hasbeen deactivated.